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mallralk/V PM (hereafter referred to as VPM) is an excellent OS/2 applica¬ 
tion development environment that provides most of the needed facilities 
(especially in release 1.3). When combined with a third-party window edit¬ 
ing product, such as WindowBuilder from Cooper and Peters, applications 
can he created easily without the OS/2 Toolkit. In a multitasking system such as OS/2, 
however, complex applications frequently need to execute multiple tasks concurrently us¬ 
ing system facilities. This article explores the implementation of VPM and discusses how 
the non-Smalltalk parts of an application can communicate with the Smalltalk parts, even 
when the non-Smalltalk parts are running in their own threads. 

INTI.RI- U ING VPM lOOTHCR I’ROIH t h 

One common requirement is an interface between application programming interfaces 
(APIs) provided by third parties and the VPM environment. Typically, these APIs are 
packaged as one or more dynamic link libraries. The most obvious way to provide the in¬ 
terface is to follow the VPM developer’s guide and create a subclass of DynamicLinklibrary 
(DLL). While this works for DLL calls that return control rapidly, it fails when control is 
kept for any length of time. The effect of this failure is to "hang” the workstation until the 
DLL call returns. To see this for yourself, evaluate the following with "Do it”: 

DosLibrary sleep: 10000 

This will cause your entire workstation to hang for the 10 seconds it takes DosSleep to 
return control. Clearly, if you can’t guarantee the DLL call will return control quickly, an¬ 
other implementation must be found. This causes particular problems for communications 
packages, since the time it takes to return control depends on the network and the partner 
program! In fact, all of the research for this article was done while developing an APPC 
interface for VPM, 

SOLVING Tl I! IN'IIRI At IN(. PR< >H1 !.M 

To an OS/2 C programmer, the solution to this problem would be simple: Create another 
thread of execution, and lec it wait for the response from the DLL call In the VPM envi¬ 
ronment, however, life is a little more complicated since it does not support OS/2 threads 
directly. An additional OS/2 thread is the best way to solve this problem. The only thing 
to be worked out is the means of communicating between VPM and the thread. OS/2 pro¬ 
vides many ways to accomplish multi-thread communication, using PM messages is the 
easiest and most robust way because PM messages are already used extensively in VPM. To 
understand how to do this, some background information is needed. 

VPM IMP! I Ml N I A I It IN 

VPM provides support for multitasking via the Process, ProcessScheduler, and Semaphore 
classes. As long as all of the sub-tasks of the application are strictly Smalltalk code, this 
method works quite well. Most VPM application developers don’t care if this multipro¬ 
cessing is simulated and does not actually use QS/2’s thread capability. This fact becomes 
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n the olden days, one of Smalltalk’s most notorious drawbacks was its inflexibility with respect to in¬ 
terfacing with software developed in other languages. Application Program Interfaces (APIs) offer a 
solution to this problem, allowing developers to interface easily with existing DLLs, regardless of the 
language in which they were developed. However, as Doug Barbour points out in our lead article this 
month, it is still not a perfect solution. If Smalltalk is using a single thread processor, it in effect 
locks up while waiting for a return from an API call. Doug describes a technique for using existing 
PM messages to let Smallralk/V PM communicate with OS/2 threads, thus providing Smalltalk pro¬ 
grammers with more control over their applications' behavior. 

This month marks the debut of a series of articles on Objectworks\Smalltalk by Dan Benson 
from the University of Washington. In Release 4, ParcPlace made many fundamental changes to 
the architecture of the graphics and user interface classes. As David Liebs and Kenny Rubin, de¬ 
scribed in last month’s issue, the changes were necessary and overdue. Unfortunately, the in-depth 
explanations and good examples needed for programmers to comprehend the changes were sadly 
lacking. Over the coming months, Dan will develop a simple graphics application he calls Small- 
Draw. His first article introduces graphics concepts and application construction with the MVC ar¬ 
chitecture through the definition of a “minimal" SmallDraw. This simplified version demonstrates 
interactive creation of geometric shapes and display of graphics. Future articles will extend the 
functionality of SmallDraw by adding selection, translation, scaling, alignment (using a 
DialogView), and grouping of objects; vertical and horizontal scrolling of the view; a cut/copy/paste 
clipboard; and support for command keys. 

It is our pleasure to welcome another well-known Smalltalk guru, Kent Beck, to the ranks of 
SMALLTALK Report columnists- Kent has been involved in many successful Smalltalk projects and 
is the co-inventor, with Ward Cunningham, of the popular Class-Responsibility-Collaborator 
(CRC) methodology for kick-starting the design of object-oriented systems. Kent’s column will 
identify Smalltalk idioms: the “coding patterns" or "mechanisms” used frequently by experienced 
Smalltalk programmers in well-defined situations, but seldom written down or explained anywhere. 
If you have ever looked at existing Smalltalk code and wondered, Why is it done chis way? Kent 
may have the answer- 

Experienced Smalltalk programmers are well aware of the virtues of separating the model from 
the user interface when developing GUI applications. In this month’s GUI column Greg Hendley 
and Eric Smith propose using a three-layer approach (Interface-Control-Model, or ICM) that fur¬ 
ther separates the UI component into an interface layer and a control layer, Simplistically, you can 
think of the interface layer as the code that would normally be generated by a window builder, and 
the control layer as the code that would respond to user interface interactions. Why separate inter¬ 
face from control? As Greg and Eric point out, one compelling reason is the speed with which sys¬ 
tems can be ported across different hosts. The interface component largely isolates the code specific 
to the host GUI from the portable control component. As a result, only the interface component 
need be ported. They illustrate the approach by building a simple log-on dialog. 

In her last column, Juanita Ewing described the differences between class variables and class in¬ 
stance variables, and lamented the fact that Smalltalk/V does not provide class instance variables. 
This month, she provides an implementation of such a facility for /V. Finally, Alan Knight provides 
us with his monthly round-up of the Smalltalk bulletin boards. 
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i^M/ST, developed by the SoftPert he 
S ystems Division of Coopers & 

Lybrand, enables the developer to 
manage large, complex, object-orient¬ 
ed applications. The AM/ST Appli¬ 
cation Browser provides multiple 
views of a developer's application. ■_ 
AM/ST defines Smalltalk/V applica¬ 
tions as logical groupings of classes and 
methods which can be managed in source 
files independent of the Smalltalk/V 
image. An application can be locked and 
modified by one developer, enabling other 
developers to browse the source code. The 
source code control system manages multi¬ 
ple revisions easily. 
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I ChangeBrowser. As an additional 
tool available forSmalltalk/VPM 
and Smalltalk/V Windows, Change- 
Browser supports browsing of the 
Smalltalk/V change log file or any 
file in Smalltalk/V chunk format. 

The addition of AM/ST to the 
ImageSoft Family of software develop¬ 
ment tools enhances and solidifies 
ImageSoffs position as — 

"The World’s Leading Publisher 
of Object-Oriented Software 
Development Tools.” 
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critical, however, when interfacing VPM to other products 
that will be called from a lower-level language such as C. 

The first thing to understand is how VPM uses OS/2 
threads. In VPM 1.3, two OS/2 threads execute when the en¬ 
vironment is running: a Presentation Manager (PM) message 
processing thread and a Smalltalk code executor thread. This 
design is based on a PM requirement that an application re¬ 
turn control to it quickly after processing a message. Since a 
PM message might (and usually does) cause Smalltalk code to 
be executed, this PM requirement could not be guaranteed us¬ 
ing a single OS/2 thread. 

In the two-thread implementation, a PM message is pro¬ 
cessed by adding it to a global OrderedCollection named Cur- 
rentEvents by the PM message processing thread. This thread 
immediately returns control to PM, allowing other applica¬ 
tions to process their PM messages. Some (typically very 
short) time later, the Smalltalk code executor thread checks 
the CurrentEvents collection to see if there are any messages. 

If any are pending, they are routed to their respective win¬ 
dow objects. Class NotificationManager performs this service 
for the code executor thread. See its instance method #nm 
for more details. 

Since PM messages are identified by a unique message 
number, VPM must have a way to translate between message 


numbers and method names. This translation is done by us¬ 
ing two global objects, PMEvents and PMEventsExtra. PMEvents is 
an array of symbols, indexed by PM message number. That 
is, (PMEvents at: 7) contains the value #wmSize:with:. Seven is 
the message number assigned to the WM_SIZE message by PM. 
The PMEvents array is not large enough to map every possible 



Figure I. VPM communication with PM through additional OS/2 thread. 
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■ OS/2 MULTI-THREADING SUPPORT 


Listing I. Creating OS/2 threads. 

#define FUNCTYPE pascal far _loadds 

#defme VPMAPPC_THREAD_QUEUE 29503 
#define VPMAPPC_STOP_THREAD 29504 


/* Function protoypes */ 

SHORT FUNCTYPE CreateThread(flYTE 'stack, USHORT stackSize, 
HWND hwnd); 

VOID FUNCTYPE Thread(); 

/' Global variables */ 

PBYTE stkbot; 

SHORT rc; 

TID thieadID=0; 

HWND notifyHwnd; 

HABhab; 

HMQ hmq; 

/* Individual Functions */ 

SHORT FUNCTYPE CreateThread(BYTE 'stack, USHORT stackSize, 
HWND hwnd) 

( 

notifyHwnd = hwnd; 

stkbot = &stack[ stackSize -1 ]; 

rc * DosCreateThread( (PFNTHREAD)Thread, AthreadlD, (VOID 
FAR *)stkbot); 

retum( rc ); 


VOID FUNCTYPE Thread() 

( 

QMSG qmsg; 

hab = Winlnitialize( NULL); /* Initialize PM •/ 

hmq = WinCreateMsgQueue( hab, 0 ); /'Create application 

msg queue */ 

WinPostMsg( notiiyHwnd, VPMAPPC_THRIAD_OUEUE, 
MPFROMLONG(hmq), OL ); 

WinGetMsgf hab, &qmsg, (HWND)NULL, 0, 0); 

while( qmsg.msg != VPMAPPC_STOP_THREAD ) 

( 


..code to process each message... 


WinGetMsg( hab, Sqmsg, (HWND)NULL, 0, 0); 

) 

WinDestroyMsgQueue( hmq); 

WinTerminate( hab ); 

) 


Listing 2. The AppcDLL class. 

DynamicLirikLibrary variableByteSubclass: #AppcDLL 
classVariableNames: " 
poolDictionaries: " 1 


!AppcDLL methods ! 

createThread: stackAddress stackSize: stackSize notifyHwnd: 
notifyHwnd 

<api: 'CREATETHREAD' ulong ushort handle ushort> 

"self invalidArgument! 


PM message. Due to memory considerations, only about the 
first 478 are mapped here. Any message numbers received 
that are greater than the size of PMEvents are looked up in the 
global Dictionary PMEventsExtra. The PM message number 
(558, for example) is the key for this dictionary, and the 
method name symbol is its value (#hmerror:with:). Once 
the PM message has been mapped to a method name via 
either PMEvents or PMEventsExtra, the PM message processing 
thread sends a Smalltalk message to the appropriate window 
object using the two arguments provided by PM. For more 
details look at any of the #wm... instance methods in the 
Window class. 

EXTENSION OF THE VPM PM INTERFACE MODEL 

The existing VPM message interface with PM is extended to 
support communications with the additional thread. This 
communication is carried out by having the chread create a 
PM message queue and passing its handle to the VPM envi¬ 
ronment. This handle is then used with the WinPostQueueMsg 
PM call to post messages to the thread. One of the message 
parameters should be the handle of the notifier window that 
is to receive notification when the request is complete. The 
thread performs whatever is requested, and posts a PM mes¬ 
sage to the notifier window. See Figure 1 for a diagram of 
this interaction. 

The first issue to be addressed is the selection of message 
numbers for communications with the thread. A consecutive 
block of message numbers should be chosen for each applica¬ 
tion, avoiding conflicts. Message numbers must be unique 
within one VPM image. User-defined message numbers must 
be greater than 4,096 to avoid conflicts with PM messages. 

For the APPC interface, message numbers range from 29,500 
to 29,505. Each message number must have an entry in 
PMEventsExtra that specifies the method name associated with 
it. For example, message number 29,501 is associated with the 
#vpmAppcVerbDone:with: method. The message definitions used 
in the APPC interface are: 


PMEventsExtra 
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| Listing 3. Creating a subclass of auxiliary window to handle PM messages. 1 

InvisibleNotifierWindow subclass: 

Private 

A self sendlnputEvent: 

#AppcNotifieiWindow 

Parameters: 

#threadQueueEvent! 

instanceVaiiableNames: 

none 


'vcbAddress threadQueue' 

Returns: 


classVariableNames:" 

self 

vpmAppcVerbDone: mpl with: mp2 

poolDictionaries:"! 

" 

* 



Description: 


"self event: #verbDone! 

A PM message has been received. 

!InvisibleNotifierWindow methods! 


Remember the parameter values, add the 


vpmAppcThreadQueue: mpl with: mp2 

message to CurrentEvents, and return to PM 

threadQueueEvent 


as soon as possible. 

" 

Description: 


Description: 

A PM message has been received. 

Role: 

A message has been received. Cause 

Remember the parameter values, add the 

Private 

the associated event to occur. 

message to CunentEvents, and return to PM 

Parameters: 


as soon as possible. 

mpl - PMLong 

Role: 


first parameter from sender 

Private 

Role: 

mp2 - PMLong 

Parameters: 

Private 

second parameter from sender 

none 

Parameters: 

Requires: 

Returns: 

mpl - PMLong 

Instance Variables: j 

self 

first parameter from sender 

vcbAddress 

' 

mp2 - PMLong 

| 


second parameter from sender 

Returns: 

A self event: #threadQueue! 

Requires: 

self 


Instance Variables: 

Ji 

verbDone 

threadQueue 
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vcbAddress := mpl deepCopy. 

Description: 

Returns: 

"self sendlnputEvent: 

A message has been received. Cause 

self 

KverbDone! ! 

the associated event to occur. 



Role: 

threadQueue := mpl deepCopy. 



Listing 4. An example of application class. 


AsyncNotifier subclass: #AppcConversation 
instanceVaiiableNames: 

'appcLibraiy notifierWindow thieadStack threadQueue sem' 
classVariableNames:" 
poolDictionaries: 

'AppcRetumCodes AppcConstants CharacterConstants ' ! 


appcLibraiy aeateThread: threadStack asParameter stackSize: 
4096 

notifyHwnd: notifierWindow handle asParameter. 

fork a process to receive messages from the thread* 
[CurrentProcess makeUserlF. Notifiei run] fork. 


!AppcConversation methods! 
initialize 


"Wait for the #vpmAppcThieadQueue:with: message" 
sem wait. 

"Re-establish the main process as the receiver of PM messages" 
CurrentProcess makeUserlF.! 


appcLibraiy := AppcDLL open. 
notifierWindow := (AppcNotifierWindow new open; 
when: #threadQueue perform: #threadQueue:; 
when: #verbDone perform: #verbDone:; 
yourself). 

sem := Semaphore new. 

threadStack := PMAddress copyToNonSmalltalkMemory: 
(ByteAnay new: 4096). 

'Create the external thread" 


threadQueue: anAppcNotifierWindow 

"Remember the thread's queue handle' 
threadQueue := anAppcNotifierWindow threadQueue. 

'Signal the main process that the message has been received" 
sem signal. 

"Terminate the message receiver process" 

Processor terminateActive.! 
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at: 29501 put: #vpmAppcVerbDone:with:; 
at: 29503 put: #vpmAppcThreadQueue:with:. 

To create an additional thread from the VPM environ¬ 
ment, a DLL must be created to issue the DosCreateThread OS/2 
call and to contain the code to be executed by the thread. In 
Listing 1, the CreateThread function performs this action. Pa¬ 
rameters to CreateThread are the stack area to be used by the 
new thread, the size of the stack area, and the window handle 
to be notified when the thread is created and ready for work. 
The stack is passed to the thread from the VPM environment 
to ensure that it is properly freed after thread termination. 

The code in the Thread function initializes PM and creates a 
message queue. It then posts the VPM_APPC_THREAD_QUEUE mes¬ 
sage to the AppcNotifierWindow instance, passing the queue han¬ 
dle as a message parameter. The Thread function then loops 
until a VPM_APPC_STOP_THREAD is received, processing mes¬ 
sages. After each message is processed, a VPM_APPC_VERB_DONE 
message is posted to the AppcNotifierWindow instance. After the 
VPM_APPC_STOP_THREAD message is received, the Thread func¬ 
tion stops looping and posts the VPM_APPC_THREAD_STOPPED 
message, which allows us to be absolutely sure the thread has 
stopped before freeing the stack area. 

A subclass of Dynanuclinklibraiy must be created to allow 
the CreateThread function to be called. The AppcDLL class is 
shown in Listing 2. 

To communicate with the thread using PM messages, there 
must be a PM window to receive them. Since this window will 
not perform any other functions, it should not be visible. This 
may be accomplished by making it a subclass of DDEAuxWindow. 
To facilitate reuse, an abstract superclass named InvisibleNoti- 
fierWindow has been created as a subclass of DDEAuxWindow. No- 
tifier windows for various functions are subclasses of this class. 
InvisibleNotifieiWindow implements the same #when:perform: in¬ 
terface as SubPane, allowing notifier windows to send messages 
to their owners when important events occur. Listing 3 shows 
some the of the methods defined for the AppcNotifierWindow. As 
you can see, there is a method corresponding to each PM mes¬ 
sage number defined in PMEventsExtra. Companion methods 
are also defined for each. The #vpmAppc... methods are exe¬ 
cuted on behalf of the PM message processing thread. They 
copy the message parameters to instance variables if necessary 
and add the message event to CurrentEvents via the #sendlnput- 
Event: method. The return from a #vpmAppc... method causes 
VPM to return control to PM, allowing other applications to 
perform window operations. 

A REAL EXAMPLE 

Let’s trace through a complete interaction sequence between 
VPM and the thread. The interaction of interest is the thread 
notifying VPM that is has created its message queue and pass¬ 
ing the queue handle as a message parameter. This is imple¬ 
mented in the initialize instance method of the AppcConversa- 
tion class and is shown in Listing 4. Here are the steps: 


• The instance of AppcDLL is created. 

• The instance of AppcNotifierWindow is created and the 
#threadQueue: event is registered, 

• A VPM Semaphore instance is created to allow waiting 
until the thread has been created, 

• The thread’s stack area is allocated as an instance of 
PMAddress. 

• The thread is started by sending the #createThread:stack- 
Size:notifyHwnd message to the AppcDLL instance. 

• A VPM process is forked to wait for the thread to respond 
with the VPM_APPC_THREAD_QUEUE message. 

• The main VPM process waits for the semaphore to be sig¬ 
naled, thus causing the application to wait without dis¬ 
turbing PM operations. 

• When the thread posts the VPM__APPC_THREAD_QUEUE mes¬ 
sage, it is processed by the forked process, which causes the 
AppcNotifierWindow instance to be sent a #vpmAppcThread- 
Queue:with: message. 

• The #vpmAppcThreadQueue:with: method makes a copy of 
the thread queue passed by the thread, adds a #thread- 
QueueEvent to CurrentEvents, and returns. At this point, 

VPM returns control to PM to allow other applications to 
perform windowing operations. 

• The forked process removes the ifthreadQueueEvent 

from CunentEvents and sends it to the AppcNotifierWindow 

instance. 

• The #threadQueueEvent sends itself the #event: message with 
#threadQueue as the argument. 

• The AppcNotifierWindow instance sends the registered 
method for the #threadQueue event (#threadQueue:) to the 
owner (the AppcConversation instance) with itself as the 
argument. 

• The #threadQueue: method assigns the thread queue to an 
instance variable and signals the semaphore. This allows 
the waiting main process to continue. 

■ The forked process is terminated by the ifthreadQueueEvent 
method. 

SUMMARY 

Using the concepts explored in this article, interfaces may be 
written from VPM to any long-running application without 
adversely affecting other applications running in the system. X 


Doug Barbour is an Information Systems Engineer at Duke Power 
Company. He is also a partner at Barbour Enterprises, specializing in 
custom interfaces to Smalltalk/V PM as well as general purpose 
classes. Doug may be reached at Barbour Enterprises , 1058 D. Kelly 
Circle, Clover SC 29710, or by phone at 803.222.1363 . 
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Release 4 


GRAPHICS AND 

MVC 


By Dan Benson 


dow is treated as a separate object. Bitmap editors, on the 
other hand, work at thepixel level. We can think of the 
main entity of the application as a “drawing” that contains 
several graphic shapes. For simplicity, we’ll limit the set of 
two-dimensional objects to: LineSegment, Rectangle, Poly¬ 
line, Polygon, and Ellipse. 

Each graphic object will have attributes that describe its 
shape. For instance, a LineSegment can be described by a start 
point and an end point, and a Polyline can be described by an 
ordered set of points. All objects will have an inside color (or 
none, in which case it will appear to be "hollow”), a border 
color, and a line width. A graphic object’s behavior should in¬ 
clude methods for accessing and modifying its attributes and 
for displaying itself at a given scale. 

The following class hierarchy defines the graphic objects 
used in SmallDraw. I’ve prefixed each class name with SD to 
distinguish it as a SmallDraw object and to avoid any naming 
conflicts when filed in to an image: 


G 


raphics often play a big role in Smalltalk applica¬ 
tions, but it is also one of the more difficult areas 
to grasp. This is particularly true of the current 
version of Objectworks for Smalltalk-80 Release 
4- Even experienced users familiar with version 2.5 can be just 
as confused as newcomers to Smalltalk because rf the major 
changes in the way graphics is handled. 

One reason for this confusion is the lack of adequate in- 
depth explanations in the users' manuals that come with 
Objectworks. You will be pleased to know that this will soon 
be remedied by new chapters scheduled for the next release 
from ParcPlace. Another source of confusion is that there 
are few examples from which to learn. This series will de¬ 
scribe a simple graphics application that might be instructive 
for those trying to get a better grip on Release 4 graphics and 
the MVC architecture. 

What better way to experiment with rendering graphics 
than to build a structured graphics editor? Commercial draw¬ 
ing programs are now commonplace, and many are quite so¬ 
phisticated. We'll borrow some ideas from these applications, 
but will keep things simple. Since we’re using Smalltalk, let’s 
call our application SmallDraw. 

We’ll start off with a “minimal” version of SmallDraw. 
We'll limit its capabilities to adding new graphic objects to 
the drawing and displaying them in a window. Additional fea¬ 
tures and functionality will be developed in future articles. 

The focus is primarily on rendering graphics on screen, so 
SmallDraw won't include such functions as saving drawings to 
files or printing to a printer. 


GRAPHIC OBJECTS 

SmallDraw is a structured graphics editor as opposed to a 
bitmap editor. In other words, each figure drawn in the win 


Object () 

SDGraphicObject ('insideColoi' 'borderColoi' "lineWidth') 
SDUneSegment ('start 'end') 

SDPolytine (“ 70111005 ') 

SDPolygon () 

SDQuadrangle () 

SDEUipse () 

The common attributes of all graphic objects are collected 
in the superclass SDGraphicObject. SDPolygon is identical to SD¬ 
Polytine except its boundary is closed- Rather than use 
Smalltalk’s Rectangle class, I defined a separate class with a 
more general name, SDQuadrangle, which inherits from SDPoly¬ 
gon, but is constrained to four vertices and 90 degree angles. 
Representing a rectangle by an origin point and a comer point 
assumes it is always aligned with the x-y axis. A more general 
representation allows rectangles to be oriented at any angle. 
I’ve defined SDEUipse as a subclass of SDQuadrangle more for con¬ 
venience of representation than semantics since an ellipse can 
be represented by its bounding rectangle and, except for dis¬ 
play, it acts just like a quadrangle. 

DISPLAYING GRAPHIC OBJECTS 

In Release 4, graphics are displayed on two-dimensional 
graphic media, all of which are subclasses of DisplaySurface. 
With the three types of display surfaces (Window, Pixmap, 
and Mask), there are two approaches one can take: display 
graphics directly on-screen using a Window, or display graph¬ 
ics off-screen using a Pixmap or Mask before final on-screen 
presentation. Off-screen rendering can result in smoother 
looking updates and eliminate “flashing,” but is a bit more in¬ 
volved, so we’ll stick with on-screen rendering for SmallDraw. 

From an object-oriented point of view, it seems reasonable 
to have the graphic objects display themselves since they 
should know best how to do that. However, we should not ex¬ 
pect these objects to know Bresenham’s line drawing algo- 
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rithm or how to turn on a red pixel, etc. The object that deals 
with these primitive operations is an instance of GraphicsCon- 
text. Each instance of a display surface has its own graphics 
context that keeps track of parameters such as line width, 
color, font, clipping rectangle, etc. The graphics context ob¬ 
ject acts as the intermediary between objects to be displayed 
and display surfaces. It maintains its local origin for its display 
surface and can display everything from images, to text, to ge¬ 
ometric shapes. 

The GraphicsContext instance methods for displaying geo¬ 
metric shapes include line segments, polylines, filled polygons, 
rectangular borders, filled rectangles, arcs, and wedges (filled 
arcs). It is through these methods that the SmallDraw graphic 
objects are able to display themselves. In SmallDraw, when an 
object is asked to display itself, it is sent an instance of a 
graphics context along with a Point that specifies the scale to 
be used. Where applicable, each type of object draws its inte¬ 
rior, if it has an inside color, and then its border, if it has a 
border color. It will first tell the GraphicsContext what color to 
use and then what shape to dr aw. SDPolygon, for instance, does 
the following: 

dlsplayOn: aGraphicsContext scale: aScalePolnt 

|pts | 

pts := self vertices collect: [:p | p * aScalePoint]. 

self insideColor isNil 

iffalse: [aGraphicsContext 

paint: self insideColor; 
displayPolygon: pts]. 

self bordeiColor isNil 

ifFalse: [aGraphicsContext 

paint: self borderColor; 
lineWidth: self lineWidth; 
displayPolyline: pts] 

Note that the displayPolygon: method displays a filled poly¬ 
gon defined by the set of points, whereas the displayPotyline: 
method displays only the boundary. GraphicsContext has similar 
methods for circular shapes as seen in the display method for 
SDEllipse: 

dlsplayOn: aGraphicsContext scale: aScalePolnt 

1 fib | 

bb := self boundingBox scaleBy: aScalePoint. 

self insideColor isNil 

iffalse: [aGraphicsContext 

paint: self insideColor; 
displayWedgeBoundedBy. bb startAngle: 0 
sweepAngle: 360 at: 0@0]. 

self borderColor isNil 

iffalse: [aGraphicsContext 

paint: self borderColor; 
lineWidth: self lineWidth; 
displayArcBoundedBy bb startAngle: 0 
sweepAngle: 360 at: 0@0] 


THE MVC ARCHITECTURE 

Smalltalk applications are constructed using the Model- 
View-Controller (MVC) architecture. A brief overview of 
the MVC paradigm will help in putting together our applica¬ 
tion. The process begins by dividing the application into two 
parts: the information model (the part that manages data 
storage and processing) and the user interface (the part that 
handles input and output). The user interface is divided fur¬ 
ther into View, which is responsible for visual output, and 
Controller, which is responsible for user input such as from 
the mouse or keyboard. 

Separating the user interface components from the infor¬ 
mation model makes it easier to "plug-in’’ other interfaces to 
the same model, connect multiple interfeces to a single model, 
or reuse interfaces for other models. The Smalltalk system is 
full of examples of using the same kinds of interface compo¬ 
nents for different sorts of models . For instance, take a look at 
the SystemBrowser or the Filelist utility. 

A model can have any number of views, whereas views 
are usually attached to a single model. Each view has only 
one controller, or none if it doesn't require user input, and 
each controller has only one view. While the model is indi¬ 
rectly connected to its view through its dependents' instance 
variable, the view and controller have instance variables 
tying them directly to each other and their model as shown 
in Figure 1. 

The model communicates with its interface components 
through a dependency mechanism. Each model maintains a 
list of its dependents and notifies them whenever changes are 
made to the model’s state. These dependents can be any kind 
of object, but are usually one or more views. A view keeps an 
eye out for certain changes in its model. When it detects any 
of those changes, it will update itself by displaying certain as¬ 
pects of its model. 

Whenever the model changes its state (in a way that may 
be of significance), it sends itself one of the following messages: 

self changed 

self changed: a Symbol 

self changed: aSymbol with: anArgument 

Which message is used depends on how much detail is nec¬ 
essary. For instance, the changed message is the most general 
and simply informs the dependents that the model has 
changed in some way, but it doesn’t tell them which aspect of 
the model has changed. Some views might only be interested 
in a particular aspect of the model, so additional information 
can determine whether or not they will respond to the change. 

The changed methods are found in the Model instance 
methods- Each changed message is eventually transformed 
into an appropriate update message that is broadcast to the 
list of dependents. The dependents must have a correspond¬ 
ing update method in which they redisplay themselves or take 
some other action: 
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update: aSymbol with: anAigument from: aModel 
update: aSymbol with: anAigumeiit 
update: aSymbol 
update 

Upon receiving an update message, a view will usually redis¬ 
play all, or a portion, of its model. For instance, in our Small- 
Draw application, when we add a new graphic object to a draw¬ 
ing, the view should be notified so that it will redisplay the 
drawing. Our model would do something like the following: 

addObject: anObject 

... code to add anObject... 

self changed: #add 

Out view would be set up to look for that particular aspect 
(#add), invalidating itself to be refreshed when found while ig¬ 
noring all other aspects: 

update: anAspect 

#add = anAspect 

ifTrue: [self invalidate] 

Controllers come into play whenever input comes from the 
mouse or keyboard. A controller usually takes control of input 
events whenever the cursor is in its view. It can be set up to 
check for keyboard events or mouse clicks, taking action 
when appropriate- Some controllers know about menus and 
how to process them for their respective views. A controller 
dealing with a menu will often direct the menu selection to it¬ 
self, its view, or its model. 

The MVC notification mechanism is automatically inher¬ 
ited when we define our application components to be sub¬ 
classes of Model, View, and Controller. Let's begin our appli¬ 
cation by describing the model where the information of 
interest is stored and processed. In this case, the model will be 
the SmallDraw object itself. The primary information it will 
keep track of is the set of graphic objects that are drawn. Ad¬ 
ditionally, it will maintain a current inside color, border colot, 
and line width that each new object will be assigned. These 
values will be initialized when the application is invoked but 
will be able to be modified through menu selections. The 
SmallDraw model will need to provide methods for adding 
new objects to the drawing and for accessing and modifying its 
other attributes. 

The Smalltalk system classes do not have a ready-made 
graphic view that will do everything that we want, so we’ll 
define our own SmallDrawView as a subclass of View. The Small- 
DrawView is responsible for displaying the graphic objects of its 
model, an instance of SmallDraw. We’ll give the SmallDrawView 
the ability to change the scale of the scene so that we ’ll be 
able to "zoom-in” or “zoom-out." It therefore will need to keep 
track of its current scale and provide some manner of chang¬ 
ing the scale. When the SmallDrawView displays itself it will ob¬ 
tain the set of objects to be displayed from its model. Then, 
the view will ask each object to display itself using the view’s 
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graphics context, scaled by the view’s display scale. As an 
aside, if we wanted to, we could design our application win¬ 
dow to contain two SmallDraw Views, with one at normal size 
and the other enlarged or reduced. Each would be a depen¬ 
dent of the same model, but would provide different perspec¬ 
tives of that model. 

We’ll also need to define our own SmallDrawController. It will 
be responsible for handling all user interaction from the 
mouse and keyboard. The two main functions of the con¬ 
troller in this application are handling menus and drawing 
new objects. If we make it a subclass of ControllerWithMenu, it 
will inherit the ability to handle menus. When the operate 
button is pressed, the controller usually obtains the menu 
from its view and processes it. For simplicity's sake, we’ll 
choose the type of object to draw from a menu. Since the con¬ 
troller handles the drawing of new objects, we’ll have it add 
its own menu selections to its view’s menu before processing. 
By contrast, most commercial applications provide a palette of 
drawing-tool buttons for selecting the type of shape to draw. 

So far, here is the hierarchy of SmallDraw MVC applica¬ 
tion classes we’ve described: 

Object 0 

Model (’dependents’) 

SmallDraw (’objects’ ’insideColor’ ’borderColor’ ‘UneWIdth’) 

VisualComponent () 

VisualPait (’container’) 

DependentPait (’model’) 

View (‘controller’) 
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SmallDrawView ('scale') 

Controller ('model' 'view” 'sensor”) 

ControllerWithMenu () 

SmallDiawController () 

MVC INTERACTION 

Because views and controllers are often designed to work 
closely together, views often specify, and even create, their 
own controllers. When the SmallDrawView needs to create 
its controller, it will ask its defaultControllerClass for one. All 
we need to do is provide a SmallDrawView instance method 
that specifies the correct controller class: 

defaultControUeiClass 

''SmallDrawController 

Connecting our MVC triad together is accomplished by 
specifying the model when the view is created: 

aSmallDiawView := SmallDrawView model: SmallDraw new. 

From this single message the view knows its model and the 
model’s dependents include the view. When the view creates 
its controller, the connections are completed. 

It may be interesting to look at the message selector inter¬ 
actions between our MVC components. We can see that the 
only interaction initiated from the model is in the update 
notification mechanism. Other than that, there are four meth¬ 
ods that the view and controller rely on from their model. If 
we had a completely different model, but one whose object in¬ 
terface included the same four selectors as SmallDraw (and 
notified dependents with #add), we could use the same view 
and controller with no changes. 

Responsibilities in the application are distributed among 
the MVC components. As such, each component has some¬ 
thing to offer the user by means of the menu. The SmallDraw 
model presents the user with options to change the default 
inside color, border color, and line width. The SmallDrawView 
allows the user to change the scale of the displayed objects, 
and the SmallDrawController offers a choice of objects to be 
drawn. Each has its own independent menu, but we need a 
way of combining them into a single menu for presentation 
on screen and a way to determine who will process the result¬ 
ing menu selection. 

The operate menu is activated by pressing the operate but¬ 
ton or by clicking in the menu bar. The SmallDrawController 
senses this and asks itself for its menu. The SmallDrawController 
menu method asks its view for its menu. If one is returned, a 
new menu is constructed combining the controller's menu 
and its view's menu. In a similar fashion, the SmallDrawView 
menu method asks its model for a menu, and answers the re¬ 
sulting combination of the two menus. 

Determining the responsible party of a menu selection re¬ 
quires the controller and view to keep track of the selectors 
each responds to. When the SmallDrawController obtains the 


user’s menu selection, it asks itself whether the menu selec¬ 
tion is one of its local menu items. If so, it responds to the se¬ 
lection. If not, it asks its view the same thing. If so, the view is 
asked to perform the selection, otherwise the model is asked 
to perform the selection. 

RUBBER BANDING 

A common technique for drawing shapes interactively on 
screen is to use “rubber banding.” Through rubber banding, 
figures appear to be stretched into shape as the cursor moves 
across the screen. For this to happen effectively, the rubber 
band lines must be alternately drawn and erased in rapid suc¬ 
cession without damaging the existing contents of the screen. 
There are different ways to accomplish this in Smalltalk, the 
simplest is to use the following Screen instance method: 

displayshape: shape lineWidth: lineWidth ah aPoint 
forMflUseconds: milliseconds 

where: 

ahape - Array of points defining the mbber band line(s) 
lineWidth - width of line(s) to be drawn 
aPoint - origin for shape in screen coordinates 
milliseconds - length of delay before erasing 

Depending on the length of delay used, the lines can ap¬ 
pear to shimmer as they are quickly drawn and erased, indicat¬ 
ing their temporary or dynamic status. From my experience, 
this technique is very effective on a Macintosh but, depending 
on the background color of the window, it can be difficult to 
see on the IBM RS/6000 platform. I don’t know the quality of 
its visual appearance on other platforms. I’ve found that a line 
width of 1 and a 25 millisecond delay works well on a Macin¬ 
tosh Ilfx. Since several methods make use of rubber banding, 
and it may be necessary to modify these parameters for differ¬ 
ent platforms, the following SmallDrawController instance 
methods are defined: 

rubberBandlineWidth 

"1 

nibberBandDelay 

*25 

Let's take a look at a very common rubber banding shape, 
the rectangle- For now, this shape will be used in drawing 
SDQuadrangles and SDEllipses, but eventually we'll use it for se¬ 
lecting groups of objects in the window. For this reason, we 
define it as a separate SmallDrawController instance method 
called rectangleFromScreen. Rectangles will be drawn on screen 
by pressing the mouse button, which defines one corner of the 
rectangle, dragging the mouse across the screen, and releasing 
the mouse button at the opposite comer of the rectangle. 
When the method is entered, it will be assumed that the 
mouse button has just been pressed. The method’s job is to 
rubber band a rectangular shape from that comer point to the 
cursor point as it is being dragged across the screen. The 
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method will return the resulting rectangle scaled to the view’s 
coordinate system: 

rectangleFroraScreen 

"Answer the resulting rectangle obtained from the user in the view's 
coordinate system. Assume the mouse is already pressed." 

| origin rectangle polygon screen lastPoint start newPoint | 

screen := Screen default. 

start := lastPoint := self sensor cursorPoint. 

origin := self sensor globalOrigin. 

rectangle := Rectangle origin: start comer: lastPoint. 

polygon := Array new: 5 withAll; start. 

[self sensor anyButtonPressed] 
whileTrue: 

[screen 

displayShape: polygon 
lineWidth: self rubberBandLineWidth 
at: origin 

forMilliseconds: self rubberBandDelay. 

(newPoint := self sensor cursorPoint) = lastPoint 
iffalse: 

[rectangle := Rectangle vertex: start vertex: 

(lastPoint := newPoint). 
polygon 

at: 1 put: rectangle topLeft; 
at: 2 put: rectangle topRight; 
at: 3 put: rectangle bottomRight; 
at: 4 put: rectangle bottomLeft; 
at: 5 put: rectangle topLeft]]. 

"rectangle scaleBy: self view displayScale reciprocal 


The rectangle is rubber banded as long as the mouse button 
is pressed, however, the shape only needs to be updated when¬ 
ever the mouse moves. Creating the rectangle with the ver- 
texrveitex: method allows the rectangle on screen to be 
stretched in any direction from the initial comer point. This 
is demonstrated below showing four different snapshots of rub¬ 
ber banded rectangles superimposed on each other: 

You may notice that the Screen instance method used for rubber 
banding applies to the entire screen and is not clipped to the con¬ 
troller's view. This can be useful for animating objects being 
"dragged’hetween windows or for drawing objects that extend beyond 
a view's bounds, but it can also possibly cause some confusion or give 
an impression of inconsistency since most other commercial applica¬ 
tions do not behave that way. 

PUTTING IT ALL TOGETHER 

In order to get our application to appear on the screen in its 
own window we use an instance of ScheduledWindow. The 
"Scheduled" part of the name indicates that its instances are 
scheduled with ScheduledControllers, the control manager. 
With Release 4, ScheduledWindows take on the "look-and- 
feeP’of the host windowing system of the specific platform on 
which it runs. This applies to only the outer portions of the 
window, such as the title bar, close, and zoom boxes. The in¬ 
terior of the window maintains the “Objectworks Smalltalk ” 
look and will appear the same across all platforms. Creating a 
ScheduledWindow and giving it a label that will appear in its ti¬ 
tle bar is straightforward: 
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aWindow := ScheduledWindow new. 
aWindow label: 'SmallDraw'. 

Now that we have a window that knows how to render it¬ 
self on the screen, we can fill it with our SmallDrawView. How¬ 
ever, we must first place a Wrapper around the view. Wrap¬ 
pers add decoration to the views they contain such as color, 
borders, layout, scroll bars, and menu bars. There are several 
types of Wrappers, beginning with the "plain brown ” Wrapper 
(no frills) to the most decorative, EdgeWidgetWrapper (all the 
frills). We’ll use the EdgeWidgetWrapper so that we can have a 
menu bar, but we’ll need to turn off the vertical scroll bar as 
each EdgeWidgetWrapper comes with a vertical scroll bar by de¬ 
fault: 


Now, to start the SmallDraw application we simply do the 
following: 

SmallDraw new open 

Incidentally, if we wanted our application window to have 
more than one subview, we would need to place our views in 
an instance of CompositePart, which would then be made the 
component of our window. CompositeParts can contain any 
number of views or other CompositeParts. Relative and absolute 
placement of subviews within composite parts is specified 
through Layouts. The following SmallDraw instance method 
opens a window containing two SmallDrawViews each occupying 
half of the window vertically: 


aWrappedView := (EdgeWidgetWrapper on: aSmallDrawView) 
noVerticalScrollBar. 

We can now place our wrapped view in the window by 
specifying it as a component of the ScheduledWindow: 

aWindow component: aWrappedView. 

Our application will be invoked by first creating an in¬ 
stance of SmallDraw and then asking it to “open” itself using 
the following SmallDraw instance method: 

open 

| aWindow aSmallDrawView aWrappedView | 
aWindow := ScheduledWindow new. 

aWindow label; 'SmallDraw'. 
aSmallDrawView:» SmallDrawView model: self. 

aWrappedView :■ (EdgeWidgetWrapper on: aSmallDrawView) 
noVerticalScrollBar. 
aWindow component: aWrappedView. 
aWindow openWithExtent: 200@200 

This, of course, could be simplified to a single statement: 


openWithTwoViews 

| window composite | 

window := (ScheduledWindow new) label: 'SmallDraw'. 
composite :■ CompositePart new. 
window component: composite, 
composite 

The left hand view." 

add: (EdgeWidgetWrapper on: 

(SmallDrawView model: self)) noVerticalScrollBar 
in: (LayoutFrame new 

leftFraction: 0; 
rightFraction: 0.5; 
topFraction: 0; 
bottomFraction: 1); 

"The right hand view." 

add: (EdgeWidgetWrapper on: 

(SmallDrawView model: self)) noVerticalScrollBar 
in: (LayoutFrame new 

leftFraction: 0.5; 

rightFraction: 1; 
topFraction: 0; 
bottomFraction: 1). 
window openWithExtent: 200@200 


open 

(ScheduledWindow new) 
label: 'SmallDraw'; 

component: (EdgeWidgetWrapper on: 

(SmallDrawView model: self)) noVerticalScrollBar; 
openWithExtent: 200@200 
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CONCLUSION 

In this article, I’ve presented a structured-graphics editor, 
SmallDraw, albeit a minimal version. I admit it’s not much of 
an editor yet, since the user can merely draw objects in the 
window. Future articles in the series will extend the function¬ 
ality of SmallDraw. We’ll add selection, translation, scaling, 
alignment (using a DialogView), and grouping of objects, ver¬ 
tical and horizontal scrolling of the view, a cut/copy/pasce 
clipboard, and support for command keys. B 


Dan Benson is a Ph.D. candidate in the Department of Electrical En¬ 
gineering at the University of Washington where he is developing a 3-D 
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by phone at 206.685.7567, or email: benson@ee.washington.edu. 
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Class instance variables for Smalltalk/V 


I n my last column, I described the effect of class variables 
and class instance variables on class reusability and con¬ 
cluded that classes implemented with class instance vari¬ 
ables are more reusable than classes implemented with class 
variables. Smalltalk-80-derived versions of Smalltalk have 
class instance variables, but Smalltalk/V versions do not. This 
column contains the code to add class instance variables to 
Smalltalk/V Windows. 

All objects in Smalltalk/V have instance variables, even 
class objects. The code in this column just makes the facility 
apparent for classes and allows users to define new class 
instance variables. 

HOW TO DEFINE CLASS INSTANCE VARIABLES 
Ordinarily, users see a class definition in a browser like the 
example in Listing 1. After the code from this column is 
added to an image, usets will see an extended class definition 
in the browser. The extended class definition consists of two 
messages, one to the class and one to the metaclass. Listing 2 
is an example of an extended class definition with no class in¬ 
stance variables. The message argument to the metaclass is an 
empty string. 

Adding a class instance variable is just like adding an in¬ 
stance variable. The user modifies the argument to the mes¬ 
sage instanceVariableNames:. The argument is a string containing 
names of class instance variables- Then the user saves the class 
definition through the menu The system redefines the class 
and recompiles as needed. Listing 3 is an extended class 
definition with a class instance variable named defaultDirection. 

IMPLEMENTING CLASS INSTANCE VARIABLES 
The code to add class instance variables to Smalltalk/V 
Windows consists of five methods, four of which are funda- 


Listing I. Class Definition for AnimatedObject. 

Object subclass: #AnimatedObject 
instanceVariableNames: 

'position oldPosition jumplnciement direction ... goCount' 
classVariableNames:" 
poolDictionaiies: 

'WinConstants' 


mental and one that is a modification to the class hierarchy 
browser. A complete listing of the code is included at the 
end of this column. 

Other versions of Smalltalk/V have different implementa¬ 
tions, and a different version of the code is necessary to imple¬ 
ment class instance variables. 

MetaClass class subclassOf: aClass 

Modified 

This is the instance creation method for MetaClass and is a 
private method. It is modified so new instances of metaclass 
have the structure of their superclass. In the original version 
of this method, each metaclass was created with the structure 
of the Class class. 

MetaClass methods instanceVariableNames: stringOflnstVarNames 

New 

This is a new method representing the public interface for 
class instance variables. This method is used to redefine the 
instance variables for a class (class instance variables). The ar¬ 
gument to this method is a string containing names of class 
instance variables. The argument is the same format as for in¬ 
stance variables and class variables. 

Class EleOutOn: aStream 

Modified 


This method has been modified to write the definition for 
class instance variables. The result of this method is also used 
to print the definition of a class in the browser. The string- 
defining class instance variable always prints even if there are 


Listing 2. Extended Class Definition for 
AnimatedObject. 

Object subclass: #AnimatedObject 
instanceVariableNames: 

‘position oldPosition jumplncrement direction... goCount' 
classVariableNames:" 
poolDictionaiies: 

'WinConstants'. 

AnimatedObject class instanceVariableNames:" 
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no class instance variables. This is necessary because the eval¬ 
uation of a class definition in the browser must return the 
same result. 


Class recreate: numberOfExtraFields 
New 


This new private method is used to recreate the class object 
when the number of class instance variables has changed. It 
deals with a number of implementation details, such as storing 
the new class in the Smalltalk dictionary and the global vari¬ 
able TableOfClasses, and inserting the new class into the class 
inheritance hierarchy. 

ClassHierarchyBrowser acceptClass: aString from: aPane 
Modified 


Listing 3. Extended Class Definition for 
AnimatedObject with a Class Instance Variable. 

Object subclass: #AnimatedObject 
instanceVariableNames: 

'position oldPosition jumplncrement direction ... goCount' 
classVariableNames: " 
poolDictionaries: 

TlVinConstants'. 

AnimatedObject class instanceVariableNames: 'defaultDirection' 


This method has been modified to update the reference to the 
selected class after saving a new definition of a class. If the 
number of class instance variables has changed, then a new 
class object will be created and the browser needs to be up¬ 
dated. This is a private method. 

COMPLETE LISTING 

MetaClass class 

subclassOf: a Class 

“Private - Answer a new metaclass that is a subclass of the metaclass 
for aClass." 

| newMeta | 
newMeta := self new. 
newMeta 

assignClassHash; 

structure: aClass class structure; 

superclass: 

(aClass = Class 
ifTrue: [Class] 
ifFalse: [aClass class]); 
methodDictionaries: 

(Array with: (MethodDictionary newSize: 2)), 
newMeta superclass methodDictionaries. 

"newMeta 

MetaClass 

InstanceVariableNames: stringOflnstVarNames 

“Define (or redefine) the set of class instance variables for the class which 
is an instance of this metaClass. The number of class instance variable 
maybe increased only if there are no existing instances of the class.” 

| theClass oldSize newSize aStream theClassName | 
theClass := self instanceClass. 
theClassName := theClass symbol. 
oldSize := self instVarNames size. 
newSize := stringOHnstVaiNames asArrayOfSubstrings size. 
oldSize < newSize 
ifTrue: 

[" if the size of the class object needs to increase 
there must be no instances" 
theClass withAUSubclasses do: 

[:aClass | aClass alllnstances notEmpty 
ifTrue: [''self error. 'Has instances']]], 
self instVarNames: stringOfinstVarNames. 
oldSize < newSize 
ifTrue: 

[theClass recreate: newSize-oldSize 
"recreate the class object"]. 
theClass := Smalltalk at: theClassName. 
aStream := WriteStream on: (String new: 64). 
theClass fileOutOn: aStream. 

Smalltalk logSource: aStream contents forClass: theClass. 
self compileAU. 
self allSubclasses do: 

[:aClass | aClass compileAU]. 

"theClass 

Class 

fileOutOn: aStream 

"Append the extended class definition message for the receiver to 
aStream. Include the statement for the definition of class instance 
variables." 
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| aString | 
aStieam cr; 

nextPutAll: self superclass printStiing; space; 
nextPutAll: self kindOfSubclass; space; 
nextPutAll: name stoieStiing; cr; space; space, 
self isBits 
ifFalse: 

[aStream nextPutAll: 'instanceVariableNames; 

(aString := self instance Variablestring) isEmpty 
ifFalse: [aStream cr; nextPutAll:'']. 
aStream 

nextPutAll: aString storestring; 
cr; space; space]. 

aStream nextPutAll: 'classVariableNames: 

(aString self classVariableString) isEmpty 
ifFalse: [aStream cr; nextPutAll:'']. 
aStream 

nextPutAll: aString storeString; 
cr; space; space; 
nextPutAll: 'poolDictionaries: 

(aString := self sharedVariableString) isEmpty 
ifFalse: [ aStream ci; nextPutAll:'']. 
aStream nextPutAll: aString storeString. 

"Include class instance variable definition.' 
aString := self class instanceVariableString. 
aStream nextPut: $.; cr. 
aStream nextPutAll: self class name. 
aStream nextPutAll:' instanceVariableNames:'. 
aStream nextPutAll: aString storeString. 
aStream cr; space; space 

Class 

recreate; numberOfExtrafields 

“Private - Replace this class object with an identical object with 
additional fields for class instance variables.' 

| newlnstance mySuperclass myName oldld | 
myName := self symbol, 
newlnstance := self class basicNew. 
oldld := self id. 

1 to: self class instSize - numberOfExtraFields 
do: 

[=i| 

newlnstance instVarAt: iput: (self instVarAt: i)J. 
mySuperclass := self superclass. 
mySuperclass removeSubclass: self. 
mySuperclass addSubclass: newlnstance. 

Smalltalk at: myName put: newlnstance. 
newlnstance methodDictionary do: 

[ ; m | 

m classField = self 

ifTrue: [m classField: newlnstance]]. 
newlnstance subclasses copy do: 

[:sub | 

sub superclass: newlnstance. 
sub recreate: numberOfExtrafields], 

TableOfClasses at: oldld + 1 put: newlnstance. 
newlnstance id: oldld. 
self become: DeletedClass 


ClassHierarchyBrowser 

acceptClass: aString from: aPane 


"Private - Accept aString as an updated 
class specification and compile it. Notify aPane if the compiler 
detects errors." 

| result isClass | 
result := Compiler 
evaluate: aString 
in: nil class 
to: nil 

notifying: aPane 
ifFail: [ / rirue]. 

Smalltalk logEvaluate: aString. 
isClass := result isKindOf: Class. 
isClass 

ifTrue: [selectedClass := result], 
self changed: #instanceVars:. 

''isClass not H 


Juanita Ewing is a senior staff member of Instantiations Inc ., a soft¬ 
ware engineering and consulting firm that specializes in developing and 
applying object-oriented software projects, and is an expert in the de¬ 
sign and implementation of object-oriented applications, frameworks, 
and systems. In her previous position at Tektronix Inc., she was re¬ 
sponsible for the development of class libraries for the first commercial- 
quality SmaUtalk-80 system. Her professional activities include Work¬ 
shop and Panel Chairs for the OOPSLA conference. 


VOSS 


Virtual Object Storage System for 

Smalltalk/V 

Seamless persistent object management with update transaction 
control directly in the Smalltalk language 

• Transparent access to Smalltalk objects on disk 

• Transaction commit/rollback 

• Access to individual elements of virtual collections and 
dictionaries 

• Multi-key and multi-value virtual dictionaries with query by 
key range and set intersection 

■ Class restructure editor for renaming classes and adding or 
removing instance variables allows incremental application 
development 

• Shared access to named virtual object spaces 

■ Source code supplied 

Some comments we have received about VOSS: 

"...dean ...elegant. Works like a charm." 

-Hal Hildebrand, Anamet Laboratories 
"Works absolutely beautifully; excellent performance and 
applicability/' 

-Raul Duran, Mkrogenics Instruments 
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VOSS/286 $595 ($375 to end of February 1992) + $15 shipping. 

VOSS/Windows $750 ($475 to end of February 1992) +$15 Shipping- 
Quantity discounts available. Visa, MasterCard and EuroCard accepted. 
Logic Arts Ltd. 75 Hemingford Road, Cambridge, England, CB1 3BY 
TEL:+44 223 212392 FAX:+44 223 245171 
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HE BEST OF comp.lang.Smalltalk 


Alan Knight 


More frequently asked questions 


T his month I continue describing and trying to answer 
some of the frequently asked Smalltalk questions 
posted on USENET-1 must be off to a bad start, be¬ 
cause much of this column is taken up with additions and 
changes from last month’s information. I guess it's the price 
we pay for working in an area of rapid change. First change: I 
said there was no official list of frequently asked questions. 
One has now been established, and I'll be incorporating infor¬ 
mation from it. The list is maintained by Craig R. Latta 
(latta@con.berkeley.edu), and is available for ftp from 
xcf.berkeley.edu. Many thanks to Craig for taking on the 
maintainer’s job. 

MORE FREE STUFF 

Last issue I listed some sources of freely available Smalltalk 
code. With a few exceptions, most of that code comes in the 
form of small ‘‘goodies." These can be system enhancements, 
bug fixes, or utilities, but are seldom large enough to be called 
applications. This is only natural. Many people are willing to 
freely contribute their own small fixes and favorite enhance¬ 
ments to the community. It takes a much greater commitment 
to contribute a large project. Generally, large projects come 
from university research projects. 

LARGER-SCALE APPLICATIONS 

The first of these is the T-Gen parser generator package, 
written by Justin Graver (graver@ufl.edu) at the University 
of Florida. The package is described as “a general-purpose 
object-oriented tool for the automatic generation of string- 
to-object translators” and is available by ftp from bikini. 
cis.ufl.edu. 

The second item is a group of packages by Stephen T. 
Pope and others, related to the Smallmusic project. This is 
“a project to discuss and develop an object-oriented system 
for music.” There is an electronic mailing list for discussions 
of the project, and several implementations and documents. 
If you have access to Internet electronic mail, you can join 
the mailing list by sending a request to smallmusic-request 
@xcf. berkeley.edu. The implementations and documents are 
available by ftp from ccrma-ftp.stanford.edu. The most re¬ 
cent implementation is called MODE (not to be confused 
with the MoDE user interface toolkit, available from the 
University of Illinois archive at st.cs.uiuc.edu). MODE 


runs under ParcPlace Smalltalk Release 4-0 and combines 
the functions of several earlier applications running under 
ParcPlace Smalltalk 2.X. 

If you’re used to commercial software, it pays to be aware 
of a few differences when dealing with ‘‘free’’ software. First, 
there are no guarantees and no toll-free customer support 
hotlines. The code may be badly written, poorly docu¬ 
mented, or nonportable. You may be able to get someone 
(possibly even the author) to help you with any problems, 
but you may not. I haven’t personally used any of the pack¬ 
ages described above, so don’t take this mention as an en¬ 
dorsement of any kind. 

Second, there may be restrictions on how the code may be 
used. Many authors retain copyright on the packges. Using all 
or part of the package in a commercial product may require an 
arrangement with the author or may not be allowed at all. 
Carefully read anything concerning copyright or licensing 
agreements. Large packages are more likely to reserve rights 
than goodies. The authors of T-Gen and the Smallmusic 
packages retain the copyright on the software. 

MANCHESTER GOODIES BY FTP 

One of the archives I mentioned last issue is at the University 
of Manchester in England. Recently, this archive became ac¬ 
cessible by ftp. The machine is called mushroom.cs.man.ac.uk 
(an alias for 130.88.13.70) and the files are available in the di¬ 
rectory pub/goodies. This machine and the archive server at 
the University of Illinois should now contain exactly the same 
material. Questions about the archive can be addressed to 
lib. manager@cs.man.ac.uk. 

SMALLTALK CHAT SESSION 

Internet Relay Chat, or IRC, is a real-time computer confer¬ 
encing program. It allows people with direct access to the In¬ 
ternet to conduct conversations without the delays of elec¬ 
tronic mail. Anyone on the Internet can participate, 
regardless of location- The drawback is the requirement for a 
direct network connection, meaning that the number of peo¬ 
ple capable of participating is much lower than in electronic 
mail or USENET forums. 

On March 3, Martin Brown (mjb@netcom.com) organized 
an IRC conference of Smalltalk users. Even though it started 
at 8:30 p.m. Pacific Time, making it awkward for eastern 
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North America and ridiculous for Europe, the conference at¬ 
tracted quite a few participants. 

IRC runs almost exclusively on UNIX machines, so almost 
all of the participants were Smalltalk-80 users. A number of 
people from ParcPlace participated, including VP Engineering 
Richard Dellinger and CEO Adele Goldberg. Highlights in¬ 
cluded a preview of features in the next ParcPlace release (in 
beta test as I write) and the opportunity to give feedback on 
features we’d like to see in future versions. It's hoped that this 
will be the first of many such conferences. 

If you’d like to participate in these conferences, you will 
need an account on a machine with a direct Internet connec¬ 
tion and a copy of the IRC program. Contact your system ad¬ 
ministrator for details. 

LANGUAGE WARS 

Like so much about computers, languages are a religious issue. 
I won’t say that this is especially bad for OOP languages, but 
it’s certainly no better than average. Many of the people on 
the net are reasonable, unprejudiced, and willing to accept 
differences of opinion. Unfortunately, a lot of them aren’t, 
and they seem to be the ones who enjoy long debates on the 
relative merits of different languages. 

Which language they are attacking or defending doesn't 
make too much difference. Each community has its own 
points of snobbery and defensiveness. Smalltalk advocates like 
to talk about pure OOP languages and about being one of the 
original sources of OOP. They become very defensive when 
anyone calls their language “slow” or “academic.” C++ advo¬ 
cates like to talk about running fast and being the most popu¬ 
lar language. They get defensive when their language is called 
“impure” or “a hack.” Eiffel advocates like to talk about soft¬ 
ware engineering principles in a pure OOPL. They get defen¬ 
sive about being called “obscure" or “proprietary.” There is 
some substance under the rhetoric, mostly concentrated in a 
few basic issues. 

MULTIPLE INHERITANCE 

Many current OOP languages make extensive use of multi¬ 
ple inheritance. Users of these languages tend to consider it 
an important part of OOP, and naturally ask why Smalltalk 
is so backward as to not support it. From the perspective of 
many in the Smalltalk community, multiple inheritance 
has been tried and judged more trouble than it’s worth. 
Besides, if you really want it, you can always write it yourself. 
For example, someone named Terry (terry@galaxia.new- 
port.ri.us) writes: 

I would like to open a discussion about multiple in¬ 
heritance in Smalltalk. To begin with, could someone who 
knows the history explain why Smalltalk does not have 
m.i.? Here are my suggestions for multiple inheritance.... 

Ralph Johnson (johnson@cs.uiuc.edu) replies with a sum¬ 
mary of the history: 


The folks at Tektronix claimed to have fixed lots of 
bugs, but they still kept running into problems, and 
finally decided that it wasn’t worth it. Implementing m.i. 
this way can be done entirely in the image. You don’t 
need to know anything about how the v.m. is imple¬ 
mented. So, anybody out there who wants to implement 
m.i. can just go ahead. If you are successful and can 
make something that people want to use then you will be 
famous, though probably not rich! 

STRONG/STATIC TYPING 

Another significant difference of opinion on programming 
languages is the matter of static vs. dynamic typing. In fact, 


ii 

Many of the people on the net are 
reasonable, unprejudiced, and willing to 
accept differences of opinion. 
Unfortunately, a lot of them aren’t. 


the existence of this argument represents one of the most re¬ 
markable achievements of C++. Almost overnight it turned 
more C programmers than I would have believed possible 
into resolute defenders of strong typing. They, along with 
Eiffel programmers, will argue that strong static typing is es¬ 
sential for good software engineering. The argument asks 
What if your air traffic control system pops up a “does not 
understand” dialogue in the middle of a forced landing? 

They also argue that strong typing enforces better design 
principles. Almost as an afterthought, they add that it makes 
programs run faster. 

On the other hand, Smalltalk, Objective-C, and other 
programmers argue that (at least with current technology) 
static typing systems either excessively restrict what pro¬ 
grams can be written or else don’t really eliminate the possi¬ 
bility of run-time type errors. Further, the errors that it 
catches are mostly those that would be trivially detected in 
testing. Better to worry about what happens when your air- 
traffic control system divides by zero. Further, they argue, the 
flexibility that you lose with static typing inhibits reuse and 
makes programming harder. 

In a lot of languages, static typing is also intimately bound 
up with multiple inheritance. In languages like C++ and Eif¬ 
fel, variables can have values of different types, but only if all 
of those types are subclasses of the declared type of that vari- 

17 . 
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Smalltalk/V users: the tool 
for maximum productivity 



3 Put related classes and methods into a single task- 
oriented object called application. 

3 Browse what the application sees, yet easily move code 
between it and external environment. 

3 Automatically document code via modifiable templates. 
3 Keep a history of previous versions; restore them with 
a few keystrokes. 

’ View class hierarchy as graph or list. 

3 Print applications, classes, and methods in a formatted 
report, paginated and commented. 

’ File code into applications and merge them together. 

’ Applications are unaffected by compress log change 
and many other features.. 


Browsers.. 


.Class 

-i Appiic ation| 


Deleted classes 
' Deleted methods 


Imager< 


| Code recovery) 


Utilities.. -; Application printing | and more.. 


CodelMAGER™ V286, VMac $129.95 
VWindow & VPM $249.95 

Shipping & handling: 513 mail, 520 UPS, per copy 
_Diskette: 1 13 1/2 □ 5 3,t| _ 



SixGraph™ Computing Ltd. 
formerly ZUNIQ DATA Corp. 
2035 Cote de Liesse, suite 201 
Montreal, Que. Canada H4N 2M5 
Tel:- ' - 

CocfcIMAGE 
Small ulk/V ■ 


able. Thus multiple inheritance is essential if the system is to 
have any flexibility at all. 

GARBAGE COLLECTION 

I’m sure you've all heard this one. What if your nuclear power 
plant has to do a garbage collect in the middle of a meltdown 
service routine? One side argues that garbage collection is thus 
a bad thing. The other says that one would have to be careful 
in using garbage collection in a hard real-time system with 
stringent response-time requirements, but that this does not 
describe most programming. 

WHO'S RIGHT' 

Ultimately, the more sensible participants will admit there are 
few, if any, universally right answers. Languages are designed 
to meet different goals. Criticizing them for not being some¬ 
thing they were not intended to be is pointless. 

To their credit, many of the better-known figures, includ¬ 
ing those closely associated with a particular language, have 
tried to defuse this sort of partisanship, There have been many 
patient explanations of the reasoning behind language fea¬ 
tures, and calm appeals to not try to use one tool for every job. 
Occasionally, though, you have to fight sarcasm with sarcasm, 
and I’d like to reproduce a particularly good example which 
appeared in comp.lang.eiffel. 

An announcement had been posted for the Tenth Eiffel 
User Conference, to be held in Dortmund, Germany, John 


Plan ahead for the largest 
object-oriented conference and 
exhibition on the East Coast in 1992 . 

Object 

THE NATIONAL CONFERENCE AND EXHIBITION 

JUNE 1-5,1992 

THE SHERATON NEW YORK 


For a detailed brochure call212*274*91 35 
or Fax: 212'274'0646 


Nagle (nagle@netcom.com) commented: 

This is the TENTH conference? And still nobody uses 
it? Maybe there’s something wrong. 

Bertrand Meyer (bertrand@eiffel.com), who invented the 
Eiffel language, responded: 

A small clarification may be useful here. As Mr. Nagle 
so competently points out, almost no one uses Eiffel; in 
fact until recently there were only nine users. But now 
a tenth person just started, so we are holding a confer¬ 
ence, appropriately titled the TENTH EIFFEL USER 
conference, to celebrate. 

The new user is in Canada, hence the word “inter¬ 
national"; this is like "world” in “world series” for 
baseball. 

We hope this helps clarify the issue, and sincerely 
apologize for any confusion the posting may have 
caused. 18 


Alan Knight is a researcher in the Department of Mechanical and 
Aerospace Engineering at Carleton University, Ottawa, Canada, K1S 
5B6. He currently works on problems related to finite element analysis 
in ParcPIace Smalltalk, and has worked in most Smalltalk dialects at 
one time or another. He can be reached at+1 613 788 2600 x5783, 
or by e-mail as knight@mrco.carleton.ca. 
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UIs 


Greg Hendley and Eric Smith 


Separating the GUI from the application 


1CM ARCHITECTURE 

Most “standard 1 ’ Smalltalk application architectures of the 
past have had just two layers: a model and an interface. 
Using the approach presented here results in a three-layer 
application. We’ll call this structure the Interface Control 
Model (1CM). 


C onsider your garden-variety Smalltalk application 
running under a GUI. Of what major parts does it 
consist? In most cases, somewhere down in the 
depths is the Domain Model. This is made up from classes 
that represent the real things users think they are manipulat¬ 
ing (e.g., transistors, diodes, connections, etc.)- All of these 
classes are commonly implemented to know as little about 
the user interface as possible. Many would agree that ideally 
the domain model objects don't even know that such a thing 
exists- This is all old hat, and we'll assume that you're famil¬ 
iar with the concept. 

The other common component of a GUI-based applic¬ 
ation is, not surprisingly, the user interface. Here is found all 
of the knowledge of what kind of widget is used to present 
which information, where it goes on the display, and what 
happens when the end user does something to it. Unfortu¬ 
nately, this part of most GUI-based applications comes in a 
lump. We'll cover how and why the UI component should be 
further divided. 

When the user interface for a GUI-based application is ex¬ 
amined, at least two broad categories of function can be 
found. The most apparent we'll call, for lack of a better term, 
the interface. The choice of display elements to be used falls 
into this category. For example, a certain set of choices may 
be offered as a list box, set of radio buttons, or pull-down 
menu. Other things in this category are the size and locations 
of such screen elements, how they respond to user input, what 
color they are, what fonts they use and so on. Anything per¬ 
taining directly to presentation or the first (or lexical) level of 
user input handling belongs in this category. 

The other broad category involves control of the applica¬ 
tion. The semantic components of an application belong in 
this category- Examples include things like “list B must be re¬ 
freshed if the user makes a new selection from list A." Other 
things that belong here are the handlers for the various com¬ 
mands (e.g., cut, copy, and paste) available to the user, or at 
least those that don't simply affect the display. 

The control category contains all of the things that define 
what it means to be the application except for the last stages 
of presentation and the first stages of input. If it involves 
knowledge of the domain model or the relationships among 
the various pieces of information presented, it belongs in 
this category. 


INTERFACE LAYER 

All of the information pertaining directly to what shows up 
on the end-user’s screen is part of the Interface layer. This 
includes the choice of display widgets, colors, fonts, menus 
vs. radio-buttons, as well as all of the first-level input han¬ 
dlers. They should normalize the input so that the Control 
layer doesn’t have to know what kind of screen widget it’s 
coming from. 

If you use a window builder of any kind for this compo¬ 
nent, you’ll be done in minutes. Except for the automatically 
generated methods used for setting up the various panes, but¬ 
tons etc., nearly all of the methods given here will be one lin¬ 
ers. They just mediate between the GUI-independent world of 
the control layer and the very GUI-dependent collection of 
user interface classes provided by Smalltalk. 

CONTROL LAYER 

This layer is where all of the work involved in producing a 
high-quality user interface ends up, This is where selected 
items mean something and where the smarts to translate user 
commands into action on the domain model live. The 
amount of thought that goes into this level will make or break 
your user interface. 

The Control layer receives messages from the Interface 
layer that inform it about what the user is doing. Some of 
these messages identify selection of options or objects. Others 
notify the Control layer of the users request that a command 
be executed. The Control layer, in turn, sends messages to the 
Interface layer to tell the interface what information is out of 
date (e.g., updateListA). 

Though the Control layer knows that the Interface layer 
exists, has a pointer to it, and even knows a few messages it can 
send it, it does not by any means know everything. The Con¬ 
trol layer should send only a very limited set of messages to the 
Interface layer. The Control layer should not even be aware of 
what class or classes the objects in the Interface layer are. 
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DOMAIN MODEL LAYER 

As mentioned above, the good old Model layer is a well- 
beaten horse. It should suffice to say that objects living down 
here know little or nothing about the fact that they even have 
an interface. They may, if they’re nice, notify unknown ob¬ 
jects above when important information has changed. 

ISOLATION 

An important aspect of the ICM approach to application de¬ 
sign is that the lower layers have as little knowledge about the 
layers above them as possible. They communicate only via a 
carefully designed protocol. The Model layer knows virtually 
nothing about the application. The Control layer knows all 
about the model, but very little about the Interface layer. It 
knows that it has an interface and knows a few messages it 
might send it (e.g., updateListA). The Interface knows nothing 
at all about the Model layer and only a little about the Con¬ 
trol layer. For example, it knows what messages to send to the 
Control layer when the user has selected something or re¬ 
quested that a command be executed. 

A QUICK EXAMPLE IN SMALLTALK/V PM 
Listing 1 provides a quick example of some of the principles 
we've just discussed. It is an implementation of the user 
name/password requestor shown in Figure 1. The first class im¬ 
plements the Interface layer. 

When the user executes a command, for example presses 
the "Ok” button to execute the "log-on” command, the inter¬ 
face does nothing more than tell the control layer that the 
user has chosen that command. At this point, the Interface 
layer is not even aware that the operation might result in a 
failure. Though the interface will be responsible for informing 
the user of such a failure (see the method for fhiotifylnvalid in 
Listing 1), it does not know where the failure occurs. 

Note that none of the application state is maintained in 
the Interface layer. The current values for the user name 
and password are all kept in the Control layer as shown in 
Listing 2. 

The class SystemLogonControl implements the control layer 
for our example application. To continue the example shown 



Figure I. User name/Puswerd Requestor. 


Listing I. An implementation of the user name/ 
password requestor. 

WindowDialog subclass: #SystemLogonDialog 
instanceVariableNames: ‘control ‘ 
classVariableNames: " 
poolDictionaries: 'WBConstants' 

bcCanceL- aFane 

‘Generated by WindowBuilder for a pane callback.” 

‘Button Command — Tell control that the user has 
chosen the 'cancel' command.' 
self control cmdCancel 

bcOk: aPane 

'Generated by WindowBuilder for a pane callback.' 

‘Button Command — Tell control that the user has 
chosen the logon’ command has been chosen. (My 
button says 'Ok' but control and I have agreed that this 
represents the logon' command).' 
self control cmdLogon 

control 

"Private — Answer the object who represents the 
control layer.' 

control isNil ifTrue: [control := self defaultControl], 

A control 

defaultControl 

‘Private — Answer the default value for control." 

A self defaultControlClass new interface: self 

defauttControlClass 

"Private — Answer the class of my default control layer." 

A SystemLogonControl 

getUserName: aPane 

"Generated by WindowBuilder for a pane callback." 

‘Ask control for his idea of what the user name is." 
aPane contents: self control userName 

notify In valid 

‘Sent only by my control layer. Tell the user that 
his log on failed." 

MessageBox 
notify:" 

withText: 'Logon Failed!!' 

open 

"The usual, large method for opening all of the views. Only the 
creation code for the important subpanes is included." 
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Listing 1. (cont'd) 

addSubpane: ( 3 

Button new 1 


owner: self; 


framingBlock: (...); 

- 

paneName: 'cancelButton'; 

addSubpane: ( 

staitGroup; 

JEntryField new 

tabStop; 

owner self; 

when: #clicked perform: #bcCancel:; 

framingBlock: (...); 

contents: 'Cancel'; 

paneName: 'userNameField'; 

yourself 

staitGroup; 

); 

tabStop; 


when: #getContents perform: #getUserName:; 


when: #textChanged perform: #setUserName:; 


yourself 


); 

openOn: aModel 

addSubpane: ( 

"Open me up on the given model." 

EntryField new 


owner: self; 

self control model: aModel. 

framingBlock: (...); 

self open 

paneName: 'paswordField'; 


staitGroup; 

MtPasaword: aPane 

tabStop; 


when: #textChanged perform: #setPassword:; 

"Generated by WindowBrnlder for a pane callback." 

yourself 


); 

"The user has changed the password. Tell control 

addSubpane: ( 

about the change." 

Button new 

self control password: aPane contents 

owner: self; 


framingBlock: (...); 

setUserName: aPane 

paneName: 'okButton'; 


defaultPushButton; 

"Generated by WindowBuilder for a pane callback." 

staitGroup; 


tabStop; 

"The user has changed the user name. Tell control 

when: #c1icked perform: #bcOk:; 

about the change." 

contents: 'Ok'; 

self control useiName: aPane contents 

yourself 

); 


in Liscing 2, if the user requests the ‘‘log-on” command, the In- 

However, we're not making these suggestions just to get you 

terface will send the message #cmdLogon to the control layer. 

to draw another box and arrow on all your slides. There are at 

As can be seen in the method for this message above, the con- 

least three considerable advantages to the ICM architecture. 

trol layer then packages up the information necessary for the 

These advantages fall in the areas of maintenance, project 

model to validate the log-on. Should the log-on be successful, 

management, and portability. 

the control layer decides that the application is at an end and 

closes things up. Otherwise, it decides the user needs to be 

MAINTENANCE 

notified of the failure. The actual notification is a presentation 

In our experience with implementing highly interactive appli- 

detail and is, therefore, left to the interface. 

cations, each of the three layers is associated with a different 

Admittedly, this is a rather simple example. However, we 

level of code volatility. Once a reasonably solid Model layer 

have used the 1CM architecture, with very satisfying results, 

has been implemented, it changes very little from vetsion to 

to implement much larger and more complex applications. 

version of the application. The code in the Control layer of- 

Scalability is not a concern with this technique. In fact, as ap- 

ten changes only a little more frequently. Several more trials 

plications grow in size, this sort of division becomes commen- 

may be required to arrive at a solid Control layer, but once ob- 

surately more important. 

tained it also changes little between versions. It is usually ex¬ 
tended rather than modified. 

SEPARATING THE HOST GUI FROM YOUR 

On the other end of the scale, the presentation aspects of 

APPLICATION 

an application can change very rapidly. These are more of- 

Adding yet another layer to the all your Smalltalk applica- 

ten modified than extended- The presentation also bears the 

tions may not sound just like what you were shopping for. 

brunt of keeping up with changes in the host GUIs. By sepa- 
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Listing 2. The Control layer. 1 

Object subclass: #SystemLogonControl 

model 

instanceVariableNames: 'interface userName password model ‘ 

"Answer the domain model (ie. the guy who knows 

classVariableNames: " 

about accounts, passwords and logon verification)." 

poolDictionaries: " 

A model 

cmd Cancel 

model: aSystemLogonManager 

"Command — The only thing that happens here is tha 

"Record the object I can ask to verify logon requests." 

the application closes up and goes away." 

model := aSystemLogonManager 

self interface close 

password 

cmdLogon 

"Answer the password. If it’s nil, it should 

"Command — The user wants to log on. We’ll give it 

default to an empty String." 

a try. If we succeed, then the application should close 
up and go away. If we fail, then the interface should 

password isNil ifTrue: [password := "]. 

confront the user with the problem." 

A password 

(self model verifyPassword: self password forllser: self userName) 

password: aString 

ifTrue: [self interface close] 
ifFalse: [self interface notifylnvalid] 

"Set the password used to verify user logon." 


password := aString 

interface 


"Answer the object which implements the interface 

userName 

layer for this application." 

"Answer the userName. If it's nil, it should 
default to an empty String." 

A interface 

userName isNil ifTrue: [userName "] . 

interface: anObject 

A userName 

"Set the object which implements the interface 
layer for this application." 

userName; aString 


"Set the account name of the user loggin on." 

interface := anObject 

userName := aString 

racing the Control from the Interface, the mote volatile as¬ 
pects of the application are isolated from the more stable 
portions. This protects the stable code from the ravages of 
constant change. 

PROJECT MANAGEMENT 

The design of the presentation of an application and of its 
control, though related, involves different skills. In some or¬ 
ganizations, different developers would be given responsibil¬ 
ity for these areas. If the application is designed with a 
monolithic user interface, the two developers’ work will be 

edge pertaining to the local host’s GUI is kept isolated in a 
small, hopefully mostly automatically generated layer. Di¬ 
alects of Smalltalk vary most widely in how they describe 
their user interface mechanisms. In applications designed us¬ 
ing the ICM approach, the portable Control code and the 
nonportable, GUI-specific code are not all run together in a 
single layer. This allows applications to be moved between 
Smalltalks very rapidly. H 

Greg Hendley is a member of the technical staff at Knowledge Systems 

hopelessly mixed and mingled. By using the ICM architec- 

Corporation. His OOP experience is in Smalltalk/V(DOS), 

ture, their work would be cleanly divided. Also, the protocol 

Smalltalk'80 2.5, Objectworks Smalltalk Release 4, and 

by which their two components communicated could be 

Smalltalk/VPM. 

easily defined. 

Eric Smith is a member of the technical staff at Knowledge Systems 
Corporation. His specialty is custom graphical user interfaces using 

PORTABILITY 

Smalltalk (various dialects) and C. 

One of the strongest reasons for using the ICM architecture is 

They may be contacted at Knowledge Systems Corporation, 114 

that it leads to applications that can be ported from one di- 

MacKenan Drive, Cary, North Carolina 27511, or by phone 

alect of Smalltalk to another very rapidly. All of the knowl- 

919.481.4000. 
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MALLTALK IDIOMS 


Kent Beck 


Why study Smalltalk idioms? 


M y dictionary defines an idiom as “a phrase whose 
meaning cannot be predicted from its words." 
While learning Smalltalk (a task that continues 
daily) I have often been puzzled by a fragment of code. Only 
upon reflection do I understand the author’s intent. About 
a year ago I began collecting examples of idioms I en¬ 
countered, and asked my friends to tell me about ones they 
found. This article is an introduction to the material I have 
collected. 

Many programmers new to Smalltalk spend most of their 
time just reading code. Studying idioms can accelerate this 
process. Knowing what to expect, or at least having some¬ 
where to turn when you are baffled by a piece of code, is im¬ 
portant to new Smalltalkets- 

Another meaning for idiom is “a style of speaking of a group 
of people-" As with spoken language, Smalltalk has several di¬ 
alects. The two most prominent are the Digitalk and Parc- 
Place dialects. There were also two distinct Tektronix di¬ 
alects, easily distinguished from one another. Xerox Special 
Information Systems (the Analyst folks) also had their own 
distinctive style. New offshoots arise anywhere Smalltalk has 
taken root for several years. 

Being conscious of the collective idiom of a body of code 
can also help more advanced programmers. Code that ad¬ 
heres to a shared idiom is easier to maintain, as there are 
fewer gratuitous surprises for new readers. Idioms also speed 
development through a kind of pattern-matching process. 
Once you have identified a circumstance in which an idiom 
is applicable, coding proceeds much faster than if you always 
have to invent new mechanisms from scratch. Standing on 
the brink of a new column, I look forward to exploring the 
range of idioms available to Smalltalk programmers. From 
time to time I’ll be joined by prominent Smalltalkers who 
will describe their favorite idioms. We will also explore 
the subtle differences between the Digitalk and the 
ParcPlace schools. 

This column will present idioms at many levels of com¬ 
plexity and scope. Rather than present all 50 or so of the 
idioms I have identified so far, 1 have chosen a smattering 
to get things going. The first few are small in scale and 
likely to trip up programmers new to Smalltalk. The con¬ 
cluding design idioms are more likely to interest more 
advanced programmers. 


CONDITIONALS AS EXPRESSIONS 
In most procedural languages, conditional statements do not 
return values. In Smalltalk, however, the result of sending 
ifTrue:ifFalse: to the Boolean "true", for example, is the value of 
the last expression in the block which is the first argument. 

This fact can be used to advantage to simplify some methods 
considerably. While you could write: 

| result | 
foo isNil 

ifTrue: [result := 5] 
ifFalse: [result := 7]. 

"result 

It is shorter (and, after you get used to it, easier) to write: 

| result | 
result := fbo isNil 
ifTrue: [5] 
ifFalse: [7]. 

"result 

Once you’ve gone that far, you can get rid of the temporary 
variable entirely and simply write: 

"foo isNil 
ifTrue: [5] 
ifFalse: [7] 

and; AND or: VERSUS & AND | 

There are two methods each for conjunction and disjunction 
in Smalltalk, and: and & both return true only if both the re¬ 
ceiver and the argument are true, and or: and | both return 
true if either the receiver or the argument are true. The differ¬ 
ence is that the keyword versions (and: and or:) take a block as 
an argument rather than a Boolean. The block is evaluated 
only if the result of the message is not determined by the re¬ 
ceiver. For instance, you should use the keyword version of 
conjunction if evaluating the argument would cause an error if 
the receiver was false. For instance, if you wrote: 

anAnay size >= 10 & (anArray at: 10) isNil 

you would get an error if anAnay held less than ten elements. 

In this case you would use the keyword version: 

anAnay size >= 10 and: [(anAnay at: 10) isNil] 
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This way the at; message is not sent if anAnay is too smalt. 
The Objectworks\ Smalltalk release 4 image uses or: to deter¬ 
mine if operating system resources (such as pixmaps) that do 
not survive over snapshots need to be reinitialized. It is com¬ 
mon to see code like this; 

(pixmap isNil or: [pixmap isOpen not]) iffrue: [pixmap := Pixmap extent... 

The other reason to use the keyword versions is for opti¬ 
mization. If the second part of a conjunction is expensive and 
the receiver is often false, using and: instead of & can result in 
a considerable savings. Why would anyone ever use the binary 
message versions of conjunction and disjunction? Style, baby. 
The keyword versions often introduce extra parentheses (as in 
the pixmap example above). They use far more characters. 
And since they are a little unusual, they require a moment of 
thought every time you encounter them. 

DEFAULT PARAMETERS 

Many programming languages provide the ability to not spec¬ 
ify certain parameters for a procedure call and have them set 
to a default value. Smalltalk provides this facility through a 
programming idiom. A displayable object, for instance, might 
implement a message display as follows: 

display 

self displayOn: Display 
which in turn is implemented as: 

displayOn: aDisplayMedium 
self displayOn: aDisplayMedium at: 0@0 

and so on, until all the parameters needed to display the object 
have been collected. As the user of this object, you can specify 
as many or as few parameters as you need to get the job done. 

The downside of implementing default parameters this way 
is the combinatorial explosion in the number of methods that 
can result. If you are creating default parameters for a method 
that has five parameters you could potentially create 5! = 120 
different methods. If you write all the possible combinations 
you obscure the purpose of the original method. If you don't 
write them all, you run the risk of not providing the combina¬ 
tion that someone needs. 

A common idiom for organizing default parameters is to 
choose a priority order. Create one method that defaults the 
most important parameter, another which specifies that pa¬ 
rameter but defaults the next most important, and so on until 
you specify all parameters. In the example above, the destina¬ 
tion for display is the most important parameter and the loca¬ 
tion, the next most important. This approach limits the num¬ 
ber of methods, but ensures that the most commonly used 
combinations are available. 

ABSTRACT SUPERCLASSES 

Some classes are not meant to be instantiated. They exist only 
as repositories for interesting related bits of behavior. The 


most powerful of these abstract superclasses reduce a set of re¬ 
lated messages to one or two methods that each concrete sub¬ 
class is required to implement. Both Smalltalks provide Collec¬ 
tion as a good example. If you create a subclass of Collection, 
you need only implement do: You get the rest of the enumera¬ 
tion methods without further effort. 

Identifying candidates for abstraction is not easy. I got the 
following strategy for using this idiom from Ken Auer of 
Knowledge Systems. If reusability is ever going to be an issue 
for a class divide it into two parts at the beginning: an abstract 
part that contains only methods, and few or no variables, and 
a concrete part that holds the state necessary to actually com¬ 
pute. The example he used had an abstract Finandallnstniment 
and a concrete Bond. As you go along, only allow state to move 
into the superclass if you can’t reasonably put it in the sub¬ 
class. By pushing implementation decisions (state) down to 
the concrete class, you have a better chance of finding what is 
truly common to the implementation of all such objects by 
examining what is left in the abstract superclass. 

Another strategy for finding abstract superclasses comes 
from Ward Cunningham. He suggests beginning an imple¬ 
mentation without using inheritance at all. Only when you 
get tired of manually copying and pasting methods from one 
class to another do you factor their commonality into a super¬ 
class for both. This strategy has the advantage that it identi¬ 
fies commonality from concrete examples. The best use of 
inheritance for code sharing is often not apparent until far 
into the design. 

VALUES MASQUERADING AS OBJECTS 
One of the glories of objects is the ease with which they can be 
passed around. But this easy mobility can become a nightmare 
if you have passed off an object and it begins to change with¬ 
out your knowledge. There is a suite of idioms for dealing with 
these aliasing problems. The one described here is the simplest, 
but it can have the greatest performance impact. If once you 
have created an object you never change its state you cannot 
possibly have aliasing. I call objects used in this way "values" 
because of their similarity to numbers. In fact, numbers in 
Smalltalk are implemented in just this way. If you have the ob¬ 
ject 10 and you add 5 to it, you don’t change 10, you get a new 
object, 15, instead- You don’t have to worry about giving away 
your 10 and having it turn into a 15 behind your back. 

Points and Rectangles are implemented much the same way. 
After you have created a Point with Number»@ all other opera¬ 
tions (+, *, translateBy:) return new Points. Unfortunately, Points 
can have their coordinates changed directly via x: and y: and 
Rectangles also offer methods for directly changing their values. 

The simplicity of value objects comes at a price. Their in¬ 
discriminate use can result in excessive memory allocation. If 
you must side-effect an otherwise functional object, do so only 
with a freshly allocated one in a small, well-defined scope 
(preferably a single method). As with all optimizations, pillag¬ 
ing a value object for speed should only be done when the 
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Product Announcements are not reviews. They are abstracted from press releases provided by vendors, and no endorsement is implied. 
Vendors interested in being included in this feature should send press releases to our editorial offices, Product Announcements Dept., 

91 Second Ave., Ottawa, Ontario K1S 2H4, Canada. 


Object Technology International Inc., (OTI) has announced a ma¬ 
jor development agreement wich International Business Machines Corpo¬ 
ration. The new agreement with IBM’s Applications Business Systems 
(ABS) will enhance the use of graphical user interfaces and objects in ap¬ 
plication development. 

ABS will work with OTI, a leading object-oriented developer, co cre¬ 
ate an object-oriented environment for developing cooperative applica¬ 
tions. OTI will combine the object-oriented ENVY/Developer technology 
with AS/400 cooperative processing support to provide a client-server ap¬ 
plication development environment for Smalltalk/V programmers. 
Smalltalk/V is an object-oriented development language provided by 
AD/Cyde International Alliance Member Digitalk Inc. 

This new development agreement is intended to enhance the capabili¬ 
ties of AS/400 programmers using graphical user interfaces, cooperative 
programming and object-oriented programming. 

For more information, contact Object Technology International Inc, 1 78 5 Woodward Drive, 
Ottawa, Ontario, Canada K1C 0P9; (613) 228-3J35. 

ExperTelllgence has announced a new version of its intelligent interac¬ 
tive graphical application development system Actlonl for version 1.3 of 
Digitalk’s’ Smalltalk/V PM. 

The new version extends Action! VI .2. It adds new CUA 91 objects 
like the Spin Button and the Slider. It also gives more control to developers 
with the powerful Properties Editor and Coordinate Windows. Finally, it al¬ 
lows interface compatibility with the Macintosh Lisp versions of Action! 

Using Action!, an interface developed in Macintosh common Lisp or 
Procyon common Lisp on a Macintosh can be instantaneously ported to 
an Intel board machine running Smalltalk/V PM. 

Acdon! V 1.3 for Smalltalk/V PM is now available directly from Ex- 
perT elligence. 

For more information, contact EjrperTetligence Inc, 5638 Hollister Avenue, Suite 302, Co- 
fcto. CA 93117; (805)967-1797. 

Digitalk Inc., the developer of the Smalltalk/V object-oriented program¬ 
ming system and a member of the IBM International Alliance for AD/Cycle, 
today announced the acquisition of Instantiations Inc. Instantiations 
provides a wide range of services to Fortune 500 companies that are de¬ 
veloping applications using Smalltalk object-oriented technology. 

Instantiations, led by object technology veteran Michael Taylor, is com¬ 


posed of some of the industry's leading object technology experts. 
Principal among these are Allen Wirfs-Brock, a well-known Smalltalk 
expert, and Rebecca Wirfs-Brock, noted author and object-oriented 
design methodologist. 

For further information, contact Digitalk Inc, 984/ Airport Boulevard, Los An geles, CA 
90045; (310) 645-1082. 

Digitalk Inc. has announced chat it is developing a 32-bit version of its 
Smalltalk/V development environment for UNIX to be delivered by year- 
end. The first platform for the company’s new UNIX technology will be 
IBM’s RS/6000 RISC (Reduced Instruction Set Chip) machine which runs 
AIX, IBM's version of UNIX. 

The new UNIX version of Smalltalk/V is abased on Digitalk’s 32-bit 
Smalltalk/V technology for OS/2 2.0. Developers can develop their applica¬ 
tions on either Smalltalk/V for OS/2 or Smalltalk/V for Windows, and 
these applications will run unmodified on the new UNIX release. 

For more information, contact Digitalk Inc, 9841 Airport Boulevard, Los Angeles, CA 90045; 
(301) 645-1082. 

Object Technology International Inc. has announced the immediate 
availability of its object-oriented product development environment. 
ENVY/Developer R1.30, for Smalltalk/V PM V1.3 and Smalltalk/V 
Windows VI. I, 

This product provides a powerful concurrent software engineering en¬ 
vironment for systems and applications development Team support ver¬ 
sion control and configuration management are seamlessly integrated with 
Smalltalk/Vs programming environment 

Release 1.30 includes ENVY/Packager, OTI's tool for delivering small, 
standalone Smalltalk applications. Developers are provided with fine¬ 
grained control over the inclusion and placement of objects included in 
the final product 

This new release supports two Smalltalk language implementations: 
Smalltalk/V Windows VI.I for Windows 3.0 and Smalltalk/V PM VI.3 for 
OS/2. Supported networks include Novell NetWare, LAN Server and 
LAN Manager. Configurations are available from three-user systems up to 
site or special corporate licenses. 

For further information, contact Object Technology International Inc, 1785 Woodward 
Drive, Ottawa, Ontario, Canada K2C 0P9; (613) 228-3535. 


performance of the finished applications is a problem for real 
users, never on mere speculation. 

CONCLUSION 

A good grasp of Smalltalk's many idioms can speed assimila¬ 
tion of the language and its class libraries, improve the pro¬ 
ductivity of new development, and accelerate understanding 
of legacy code. This article has only scratched the surface of 
known Smalltalk idioms, all of which were present in 
Smalltalk-80 as it escaped from Xerox. The dispersion of 


Smalltalk will fuel the growth of many new idioms. 

I am still collecting idioms. If you identify one you would 
like to share, contact me. H 


Kent Beck has been discovering Smalltalk idioms for eight years at 
Tektronix, Apple Computer, and MasPars Computer. He is also the 
founder of First Class Software, which develops and distributes re¬ 
engineering products for Smalltalk. He can be reached at P.O. Box 
22 6, Boulder Creek, CA 95006 or kentb@maspar.com. 
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WHAT THEY’RE SAYING 
ABOUT SMALLTALK 


Excerpts from industry publications 


...Changing the way you develop software is a nontrivial decision. 

You are not going to take seasoned FORTRAN or C programmers 
and turn them into Smalltalk wizards overnight You are likely, how¬ 
ever, to find one or more programmers in your development group 
who are highly interested in object technology. These self-motivated, 
early adopters are good candidates for a core transition team within 
your development group. But they must be given training in object- 
oriented analysis and design as well as Smalltalk programming. (Impor¬ 
tant tip: A Smalltalk programmer with a structured, procedural mind¬ 
set is not really a Smalltalk programmer)... 

Technology. Smalltalk speaks to users'needs, Jim Salmons and Timlynn 
Babitsky, Open Systems Today, 2117/92 


...Practical studies based on function point analysis show that a 4GL 
solution to a typical problem is 50% simpler chan 3GL solution, but 
only 15% simpler than an OOPL solution. This is probably because 
the OOPL's user-defined types are counted, while those built into the 
4GL are not. The size and complexity of a 4GL solution grows incre¬ 
mentally with the system. With an OOPL, you just add components 
to meet each new challenge. Fourth-generation and other specialized 
languages will stick around, if only for cultural reasons (most of to¬ 
day's programmers cut their teeth on them). The world is unlikely to 
rally around a single OOPL. Technical and financial developers use 
C++. MIS shops prefer Smalltalk or are waiting for object-oriented 
Cobol. Ironically, object-oriented 4GLs now accompany some OO 
databases to help them integrate objects from multiple OOPLs. 

Software & Systems: Fourth generation heyday at an end, 
Craig Hubley, Computing Canada, 2117192 


...At press time [Sequent's Larry] Evans didn't want to elaborate on 
Ptx/Object, but according to documents obtained by UNIX 
WORLD, the product will combine a parallel version of the Parc- 
Place Objectworks/Smalltalk development environment and a paral¬ 
lel implementation of Versant Object Technology Corp.'s object 
database management system. This will enable users to tap informa¬ 
tion from legacy systems and convert it to objects... 

Because the object-oriented market is in its infancy, Ptx/Object 
won't generate any short-term income. As the object-oriented mar¬ 
ket becomes more mature, however. Sequent’s early entrance will 
help it, say analysts... 

Sequent's software cure, Cary Andrew Poole, UNIX World, 3192 


...But we [Microsoft] also expected (and predicted) that "OOP" 
would become a vendor buzzword long before great OOP solutions 
were generally available. Our concern was to ensure that the press 
did not treat OOP as an end in itself, but merely as a means: to 
make software easier to design and maintain for developers: to 
make applications easier to use and more functional for end users. If 
OOP does not provide these benefits, then it remains only an 
acronym, not a solution,. ..Our concerns about OOP being over¬ 
sold, however, remain. Object-oriented tools and systems are the 
most sophisticated and complicated of any software products ever 
built. Object orientation is not something that can be tacked onto 


an existing system; it must be designed in. It is very difficult to do 
right, technically. And the focus must always remain on providing 
real value to the consumer... 

Object insider Bill Gates, Object Magazine, 3-4192 


.. .There is a creative tension building in the computer industry be¬ 
tween the “way we used to do it" and the "way we should do it” Ob¬ 
ject technology is causing this tension, as the vision of the way we 
should do it clashes with current reality. There is only one way to re¬ 
solve this tension we find ourselves in: either pull the vision of object 
technology towards reality, or pull reality toward the vision... 

Object Request Broker—the end of the beginning, 
Chris Stone, Ob/ect Magazine, 3-4/92 


...In the longer term, it will be up to content specialists to define 
the basic services that classes should provide in a way that makes 
them more independent of their implementation context... 

...In addition to warranties and certification processes, I believe 
that class vendors should provide testing facilities with every class 
they ship. Ideally, these facilities would include a complete test bed for 
automatically sending a full range of messages to the class and check¬ 
ing the correctness of its responses. Providing developers with these 
testing tools would allow them to double check the performance of 
any class. More importantly, it would help them assure that any modi¬ 
fications or subclassing they performed had not violated the basic 
functionality of the class... 

...Ultimately, the solution to compensating class creacors will be 
determined by market forces, which usually have a way of defying the 
most well-intentioned attempts at prediction... 

Easing into objects: developing the object components industry, 
David A. Taylor, Ob/ect Magazine, 3-4/92 


...The changing nature of systems, however, including a move to dis¬ 
tributed development and deployment, the increased use of graphical 
user interfaces, improvements in language and environment technol¬ 
ogy, and widespread availability of classes and libraries, will speed the 
adoption of object-oriented programming languages. Large systems 
of the future will evolve on a project or functional basis rather than 
as multi-year phased systems. As the world migrates to reusable 
components and the development of organic systems, small methods 
will once again dominate. A method like IE, based on the mainframe- 
centric master enterprise model view of the world, will ultimately 
collapse under its own weight When objectified versions appear, 
view them with caution, and ask if the problems they are solving will 
be relevant to you by the time you complete your enterprise model. 

Methodology objectified information engineering—the method time bomb?, 
Adrian Bowles, Object Magazine, 3-4192 


...Relational vendors believe that by extending the capabilities of 
their database servers, or the capabilities of some front-end tools, 
many of the benefits of object technology can be achieved without 
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adopting a new database model. Sybase's [VP of marketing, Stewart] 
Schuster referred to object technology as a “natural extension" 
rather than a "fundamental paradigm shift." [Mary] Loomis [VP of 
technology for Versant Object Technology] noted that RDBMSes 
have stored procedures and BLOBS, but claimed that was not ade¬ 
quate. “They are baby steps,” Loomis said. "Some RDBMSes have 
stored procedures which begin to put some actions in the databases, 
but they’re in a very [limited] way. They really don’t couple the data 
with the action. Object databases are much more than BLOBS. 

SPARC databases square off, Barry D. Bowen, 
O pen Systems Today, 2117192 


...According to the January/February 1992 issue of PC Al, the value 
of the relational database market in 1980 was $2 million, but in 1990 
it was $2.5 billion. Similarly, the value of the object-oriented market 
today is $10 million. By 1995, PC Al estimates the value will sky¬ 
rocket to $235 million... 

Quick statistics, Computor Edge, 217192 

...Now they're scrambling to recreate their [CASE] programs to write 
software for desktop machines and local area networks. Many of the 
big mainframe CASE vendors, including IBM, Texas Instruments Inc., 
and Andersen Consulting, are already coming out with new products 
for these markets.. .Otherwise, there will be a reapportioning of IS 
dollars in favor of smaller CASE vendors...Such as object-oriented 
programming environments. AT&T, for instance, is using an object-ori¬ 
ented CASE program called Teamwork from Cadre Technologies Inc. 
of Providence, Rl, to build a piece of its 911 service. The object-ori¬ 
ented technology combined with CASE programming capabilities, says 
AT&T systems engineer Michael Krass, lets the company write code 
that can be easily reused and maintained—unlike traditional CASE... 

The case against CASE, Robert Moran, 
Information Week, 21 17/92 


...[Sun Microsystem's R.G.G.] Cattell made a couple of observations 
on choosing among the available object databases: "For the object 
database in question, look at the power of the query languages for 
associative retrieval or queries across sets of objects. Second, how 
well are they integrated with a programming language?" In some ar¬ 
eas, the differences among commercial offerings are minor. "Based 
on the [Cattell] benchmarks, there is not much difference in perfor¬ 
mance among the object databases. Further more, the size of the 
benchmark database is not important There is no storage-require¬ 
ment penalty." He said he would choose a database largely on the 
basis of the company and its stability. "The technical differences are 
small.” What about writing your own? “I would lean toward buying," 
Cattell said. “You can always build something faster relative to what 
you can get off the shelf, but the performance of the commercial ob¬ 
ject databases is quite impressive.” 

Guidelines for choosing the best database technology, 
Robert H. Blissmer, Electronic Engineering Times, 2117192 


...[Gartner Group's David Stein]"Object technology is probably the 
most significant development in software technology in 40 years. Like 
all major baseline technology shifts, this one won't be felt immediately, 
but over a 10-year period. A massive amount of development has to 
be done, but this is so far-reaching in its effects that it will impact lit¬ 
erally everything that's being done with software. You now have the 


ability to standardize, and that changes the economics of software 
development, which is where the big bucks are spent..." 

[Merrill Lynch & Co.'s Anthony Pizi]"...Multimedia is the future 
for training. It allows people to learn at their own pace. This technol¬ 
ogy is very good for training people in a standardized way. A firm's 
staff might be spread out among five different offices, but they can all 
use the same training program. Investment bankers might use multi- 
media to give a presentation to a client and make changes on the fly. 
But one of the biggest problems is portability. You need either 
tremendous amounts of memory or a U-haul to lug all the hardware 
like CD player, CPU and monitor. Live video is on its way, but any 
time you incorporate video and sound, huge files are created, which 
have to be compressed. More "affordable" boards are coming out so 
end users don't have to worry about losing any data..." 

[Andersen Consulting—Financial Markets Industry Group’s 
Robert Gach]"...Rule-based processing and object-oriented devel¬ 
opment are technologies that firms on the Street could use to steer 
clear of large applications, which have millions of lines of code and 
don't lend themselves to flexible new product development. Ob¬ 
ject-oriented technology and maximizing code reusability—changing 
something, copying it or adding a variant—as opposed to starting 
from scratch, would save the Street a lot of development costs and 
time. Applications would get to traders faster if programmers could 
reuse packets of logic that are two to three commands long. Appli¬ 
cations with only 30% to 40% of the code are easier to maintain, 
document, understand and fix. In addition, by using both these 
technologies, programmers stay in the end user’s world and define 
systems from a business standpoint...’’ 

Hot technologies for the 1990s, Ann Goodman and 
Jenna Michaels, Wau. Street & Technology, 2192 


...[Computer Associates’ Dominique Laborde:]”The industry is 
beginning to pay attention to object-oriented programming... 

IBM does not have any products in this category but needs to say 
something about an object-oriented DBMS. So the company pub¬ 
lished a broad list of specifications. Right now, those specifications 
are not mature enough for us or anyone else to support."... 

Data access solution now has IBM road mop, 
Paul Korzeniowski, Software Magazine, 2/92 


...The constant refrain heard among the audience [at PC Forum] 
was this: We shouldn't talk about objects because nobody agrees 
what they are, users don't see them, and nobody really has them. 
The notion was that objects are sort of the industry's dirty laundry, 
so they really shouldn't be hung out in decent company...We dis¬ 
agree. Objects should not be swept under the rug. We know that 
the notions of object orientation have been around the industry 
since the early 1970s. But we believe that the technology infrastruc¬ 
ture is only now becoming sufficiently powerful and sophisticated so 
those notions can be implemented in everyday systems. And we 
think that development will change everything about computing for 
our readers. And we mean everything, including whac skills you need 
to be successful, what kind of products you should invest in, the 
methods you use to evaluate those products, the expectations you 
have (and set for your management) about how fast you can imple¬ 
ment new applications, and the approaches you choose to adopt in 
designing your systems...A key benefit of object-based systems, for 
instance, should be to move the locus of responsibility for applying 
technology from the vendor...to the customer... 

Editorial: Object-oriented technology needs to be thrashed out, 
Stevrart Alsop, I nfoworld, 312192 
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WIDOWS AD OS/2: 
PROTOTYPE TO DELIVERY. 
NOWATHG. 

In Windows and OS/2, you need prototypes. You have to get a sense 
for what an application is going to look like, and feel like, before you can write 
it. And you can’t afford to throw the prototype away when you’re done. 

With Smalltalk/Y you don’t. 

Start with the prototype. There’s no development system you can buy 
that lets you get a working model working faster than Smalltalk/V 

Then, incrementally, grow the prototype into a finished applica¬ 
tion. Try out new ideas. Get input from your users. Make more changes. 

Be creative. 

Smalltalk/V gives you the freedom to experiment without risk. It’s 
made for trial. And error. You make changes, and test them, one at a time. 
Safely. You get immediate feedback when you make a change. And you can’t 
make changes that break the system. It’s that safe. 

And when you’re done, whether you’re writing applications for 
Windows or OS/2, you’ll have a standalone application that runs on both. 
Smalltalk/V code is portable between the Windows and the OS/2 versions. 
And the resulting application carries no runtime charges. All for just 

8499 . 95 . 

So take a look at _ /'W F 

Smalltalk/V today. It’s time to make f 'w 

that prototyping time productive. 

Smalltalk/V is a registered trademark of Digitalk, Inc. Other product names are trademarks or registered 
trademarks of their respective holders. 

Digitalk, Inc., 9841 Airport Blvd., Los Angeles, CA 90045 
(800) 922-8255; (213) 645-1082; Fax (213) 645-1306 


LOOK WHO’S TALKING 


HEWLETT-PACKARD 
HP has developed a network trouble¬ 
shooting tool called the Network Advisor. 
The Network Advisor offers a comprehen¬ 
sive set of tools including an expert system, 
statistics, and protocol decodes to speed 
problem isolation. The NA user interface is 
built on a windowing system which allows 
multiple applications to be executed 
simultaneously. 


NCR 

NCR has an integrated test program develop¬ 
ment environment for digital, analog and 
mixed mode printed circuit board testing. 

MIDLAND BANK 

Midland Bank built a Windowed Technical 
Trading Environment for currency, futures 
and stock traders using Smalltalk V 


KEY FEATURES 

■ World’s leading, award-winning object- 
oriented programming system 

■ Complete prototype-to-delivery system 

■ Zero-cost runtime 

■ Simplified application delivery for 
creating standalone executable (.EXE) 
applications 

■ Code portability between Smalltalk/V 
Windows and Smalltalk/V PM 

■ Wrappers for all Windows and OS/2 
controls 

■ Support for new CUA VI controls for 
OS/2, including drag and drop, booktab, 
container, value set, slider and more 

■ Transparent support for Dynamic Data 
Exchange (DDE) and Dynamic Link 
Library (DLL) calls 

■ Fully integrated programming environ¬ 
ment, including interactive debugger, 
source code browsers (all source code 
included), world s most extensive Win¬ 
dows and OS/2 class libraries, tutorial 
(printed and on disk), extensive samples 

■ Extensive developer support, including 
technical support, training, electronic 
developer forums, free user newsletter 

■ Broad base of third-party support, 
including add-on Smalltalk/V products, 
consulting services, books, user groups 



This Small talk/V Windows application 
captured the PC Wfeek Shootout award—and 
it was completed in 6 hours. 



Smalltalk/V PM applications are used to 
develop state-of-the-art CUA-compliant 
applications—and they’re portable to 
Smalltalk/V Windows. 

















